System, method and program product for modifying a supply of stable value digital asset tokens

ABSTRACT

The present invention generally relates to a method, system and program product for modifying a supply of stable value digital asset tokens tied to a blockchain.

REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.16/688,465, filed on Nov. 19, 2019 and entitled SYSTEM, METHOD ANDPROGRAM PRODUCT FOR MODIFYING A SUPPLY OF STABLE VALUE DIGITAL ASSETTOKENS, which is a continuation of and claims priority to U.S. patentapplication Ser. No. 16/421,975, filed on May 24, 2019 and entitledSYSTEM, METHOD AND PROGRAM PRODUCT FOR MODIFYING A SUPPLY OF STABLEVALUE DIGITAL ASSET TOKENS, which is a continuation of U.S. patentapplication Ser. No. 16/293,531, filed on Mar. 5, 2019 and entitledSYSTEM, METHOD AND PROGRAM PRODUCT FOR MODIFYING A SUPPLY OF STABLEVALUE DIGITAL ASSET TOKENS which claims the benefit of and priority toeach of U.S. Provisional Application No. 62/638,679, filed on Mar. 5,2018 and entitled SYSTEM, METHOD AND PROGRAM PRODUCT FOR GENERATING ANDUTILIZING STABLE VALUE DIGITAL ASSETS; U.S. Provisional Application No.62/647,353, filed on Mar. 23, 2018 and entitled SYSTEM, METHOD ANDPROGRAM PRODUCT FOR GENERATING AND UTILIZING STABLE VALUE DIGITALASSETS; U.S. Provisional Application No. 62/660,655, filed on Apr. 20,2018 and entitled SYSTEM, METHOD AND PROGRAM PRODUCT FOR GENERATING ANDUTILIZING STABLE VALUE DIGITAL ASSETS; U.S. Provisional Application No.62/683,412, filed on Jun. 11, 2018 and entitled SYSTEM, METHOD ANDPROGRAM PRODUCT FOR GENERATING AND UTILIZING STABLE VALUE DIGITALASSETS; U.S. Provisional Application No. 62/689,563, filed on Jun. 25,2018 and entitled SYSTEM, METHOD AND PROGRAM PRODUCT FOR GENERATING ANDUTILIZING STABLE VALUE DIGITAL ASSETS; U.S. Provisional Application Ser.No. 62/764,977, filed on Aug. 17, 2018 and entitled SYSTEM, METHOD, ANDPROGRAM PRODUCT FOR MODIFYING A SUPPLY OF STABLE VALUE DIGITAL ASSETTOKENS; U.S. Provisional Patent Application Ser. No. 62/721,983, filedon Aug. 23, 2018 and entitled SYSTEM, METHOD, AND PROGRAM PRODUCT FORMODIFYING A SUPPLY OF STABLE VALUE DIGITAL ASSET TOKENS; and U.S.Provisional Patent Application Ser. No. 62/728,441, filed on Sep. 7,2018 and entitled SYSTEM, METHOD, AND PROGRAM PRODUCT FOR MODIFYING ASUPPLY OF STABLE VALUE DIGITAL ASSET TOKENS, the entire content of eachof which is hereby incorporated by reference herein.

U.S. patent application Ser. No. 16/293,531, filed on Mar. 5, 2019 andentitled SYSTEM, METHOD AND PROGRAM PRODUCT FOR MODIFYING A SUPPLY OFSTABLE VALUE DIGITAL ASSET TOKENS also claims priority as acontinuation-in-part to U.S. patent application Ser. No. 16/036,469,filed on Jul. 16, 2018 and entitled SYSTEM, METHOD, AND PROGRAM PRODUCTFOR DEPOSITING AND WITHDRAWING STABLE VALUE DIGITAL ASSETS IN EXCHANGEFOR FIAT, which in turn is a continuation-in-part of U.S. patentapplication Ser. No. 16/020,534, filed on Jun. 27, 2018 and entitledSYSTEM, METHOD, AND PROGRAM PRODUCT FOR GENERATING AND UTILIZING STABLEVALUE DIGITAL ASSETS, which in turn is a continuation-in-part of U.S.patent application Ser. No. 15/960,040, filed on Apr. 23, 2018 andentitled SYSTEM, METHOD AND PROGRAM PRODUCT FOR GENERATING AND UTILIZINGSTABLE VALUE DIGITAL ASSETS, which claims priority to and the benefit ofeach of U.S. Provisional Patent Application No. 62/660,655, filed onApr. 20, 2018 and entitled SYSTEM, METHOD AND PROGRAM PRODUCT FORGENERATING AND UTILIZING STABLE VALUE DIGITAL ASSETS, U.S. ProvisionalPatent Application No. 62/647,353, filed on Mar. 23, 2018 and entitledSYSTEM, METHOD AND PROGRAM PRODUCT FOR GENERATING AND UTILIZING STABLEVALUE DIGITAL ASSETS, and U.S. Provisional Patent Application No.62/638,679, filed on Mar. 5, 2018 and entitled SYSTEM, METHOD ANDPROGRAM PRODUCT FOR GENERATING AND UTILIZING STABLE VALUE DIGITALASSETS, the entire content of each of which is hereby incorporated byreference herein.

U.S. patent application Ser. No. 16/293,531, filed on Mar. 5, 2019 andentitled SYSTEM, METHOD AND PROGRAM PRODUCT FOR MODIFYING A SUPPLY OFSTABLE VALUE DIGITAL ASSET TOKENS also claims priority as acontinuation-in-part to U.S. patent application Ser. No. 15/960,040,filed on Apr. 23, 2018 and entitled SYSTEM, METHOD AND PROGRAM PRODUCTFOR GENERATING AND UTILIZING STABLE VALUE DIGITAL ASSETS, which claimspriority to and the benefit of each of: U.S. Provisional PatentApplication No. 62/660,655, filed on Apr. 20, 2018 and entitled SYSTEM,METHOD AND PROGRAM PRODUCT FOR GENERATING AND UTILIZING STABLE VALUEDIGITAL ASSETS, U.S. Provisional Patent Application No. 62/647,353,filed on Mar. 23, 2018 and entitled SYSTEM, METHOD AND PROGRAM PRODUCTFOR GENERATING AND UTILIZING STABLE VALUE DIGITAL ASSETS, and U.S.Provisional Patent Application No. 62/638,679, filed on Mar. 5, 2018 andentitled SYSTEM, METHOD AND PROGRAM PRODUCT FOR GENERATING AND UTILIZINGSTABLE VALUE DIGITAL ASSETS, the entire content of each of which ishereby incorporated by reference herein.

U.S. patent application Ser. No. 16/293,531, filed on Mar. 5, 2019 andentitled SYSTEM, METHOD AND PROGRAM PRODUCT FOR MODIFYING A SUPPLY OFSTABLE VALUE DIGITAL ASSET TOKENS also claims priority as acontinuation-in-part to U.S. patent application Ser. No. 16/020,534filed on Jun. 27, 2018 and entitled SYSTEM, METHOD, AND PROGRAM PRODUCTFOR GENERATING AND UTILIZING STABLE VALUE DIGITAL ASSETS, which claimsthe benefit of and priority to each of U.S. Provisional PatentApplication Ser. No. 62/689,563, filed on Jun. 25, 2018 and entitledSYSTEM, METHOD AND PROGRAM PRODUCT FOR GENERATING AND UTILIZING STABLEVALUE DIGITAL ASSETS; and U.S. Provisional Patent Application No.62/683,412, filed Jun. 11, 2018 and entitled SYSTEM, METHOD AND PROGRAMPRODUCT FOR GENERATING AND UTILIZING STABLE VALUE DIGITAL ASSETS, theentire content of each of which is hereby incorporated by referenceherein.

U.S. patent application Ser. No. 16/036,469 also claims the benefit ofand priority to each of U.S. Provisional Patent Application Ser. No.62/689,563, filed on Jun. 25, 2018 and entitled SYSTEM, METHOD ANDPROGRAM PRODUCT FOR GENERATING AND UTILIZING STABLE VALUE DIGITALASSETS; and U.S. Provisional Patent Application No. 62/683,412, filedJun. 11, 2018 and entitled SYSTEM, METHOD AND PROGRAM PRODUCT FORGENERATING AND UTILIZING STABLE VALUE DIGITAL ASSETS, the entire contentof each of which is hereby incorporated by reference herein.

U.S. patent application Ser. No. 16/293,531, filed on Mar. 5, 2019 andentitled SYSTEM, METHOD AND PROGRAM PRODUCT FOR MODIFYING A SUPPLY OFSTABLE VALUE DIGITAL ASSET TOKENS also claims priority as acontinuation-in-part to U.S. patent application Ser. No. 16/282,955,filed on Feb. 22, 2019 and entitled SYSTEMS, METHODS, AND PROGRAMPRODUCTS FOR DEPOSITING, HOLDING, AND/OR DISTRIBUTING COLLATERAL AS ATOKEN IN THE FORM OF DIGITAL ASSETS ON AN UNDERLYING BLOCKCHAIN, whichin turn is a continuation-in-part to U.S. Non-Provisional patentapplication Ser. No. 16/280,788, filed Feb. 20, 2019 and entitledSYSTEMS, METHODS, AND PROGRAM PRODUCTS FOR LOANING DIGITAL ASSETS ANDFOR DEPOSITING, HOLDING AND/OR DISTRIBUTING COLLATERAL AS A TOKEN IN THEFORM OF DIGITAL ASSETS ON AN UNDERLYING BLOCKCHAIN, which in turn claimspriority to U.S. Provisional Application Ser. No. 62/684,023 filed onJun. 12, 2018 and entitled SYSTEMS, METHODS, AND PROGRAM PRODUCTS FORLOANING DIGITAL ASSETS; U.S. Provisional Application No. 62/680,775,filed on Jun. 5, 2018 and entitled SYSTEMS, METHODS, AND PROGRAMPRODUCTS FOR LOANING DIGITAL ASSETS; U.S. Provisional Application No.62/702,265, filed on Jul. 23, 2018 and entitled SYSTEMS, METHODS, ANDPROGRAM PRODUCTS FOR LOANING DIGITAL ASSETS AND FOR DEPOSITING, HOLDING,AND/OR DISTRIBUTING COLLATERAL AS A TOKEN ON AN UNDERLYING BLOCKCHAIN;U.S. Provisional Patent Application Ser. No. 62/764,978, filed on Aug.17, 2018 and entitled SYSTEMS, METHODS, AND PROGRAM PRODUCTS FORGENERATING USER DEFINED SMART CONTRACTS AND DEPOSITING, HOLDING AND/ORDISTRIBUTING COLLATERAL AS A TOKEN IN THE FORM OF DIGITAL ASSETS ON ANUNDERLYING BLOCKCHAIN; and U.S. Provisional Patent Application Ser. No.62/732,347, filed on Sep. 17, 2018 and entitled SYSTEMS, METHODS, ANDPROGRAM PRODUCTS FOR GENERATING USER DEFINED SMART CONTRACTS ANDDEPOSITING, HOLDING AND/OR DISTRIBUTING COLLATERAL AS A TOKEN IN THEFORM OF DIGITAL ASSETS ON AN UNDERLYING BLOCKCHAIN, the entire contentof each of each of which is hereby incorporated by reference herein.U.S. Non-Provisional patent application Ser. No. 16/280,788 also claimspriority as a continuation-in-part to U.S. Non-Provisional patentapplication Ser. No. 15/973,140, filed on May 7, 2018 and entitledSYSTEMS, METHODS, AND PROGRAM PRODUCTS FOR EXCHANGING DIGITAL ASSETS FORFIAT AND/OR OTHER DIGITAL ASSETS, which in turn claims priority to U.S.Provisional Patent Application Ser. No. 62/660,655, filed on Apr. 20,2018 and entitled SYSTEM, METHOD AND PROGRAM PRODUCT FOR GENERATING ANDUTILIZING STABLE VALUE DIGITAL ASSETS, U.S. Provisional PatentApplication Ser. No. 62/642,946, filed on Mar. 14, 2018 and entitledSYSTEMS, METHODS, AND PROGRAM PRODUCTS FOR EXCHANGING DIGITAL ASSETS FORFIAT AND/OR OTHER DIGITAL ASSETS, U.S. Provisional Patent ApplicationSer. No. 62/642,931, filed on Mar. 14, 2018 and entitled SYSTEMS,METHODS, AND PROGRAM PRODUCTS FOR EXCHANGING DIGITAL ASSETS FOR FIATAND/OR OTHER DIGITAL ASSETS, and U.S. Provisional Patent ApplicationSer. No. 62/629,417, filed on Feb. 12, 2018 and entitled SYSTEMS,METHODS, AND PROGRAM PRODUCTS FOR VERIFYING DIGITAL ASSETS HELD IN ACUSTODIAL DIGITAL ASSET WALLET, the entire content of each of which ishereby incorporated by reference herein. U.S. Non-Provisional patentapplication Ser. No. 16/280,788 also claims priority as acontinuation-in-part to U.S. Non-Provisional patent application Ser. No.15/960,040, filed on Apr. 23, 2018 and entitled SYSTEM, METHOD ANDPROGRAM PRODUCT FOR GENERATING AND UTILIZING STABLE VALUE DIGITALASSETS, which in turn claims priority to U.S. Provisional PatentApplication Ser. No. 62/660,655, filed on Apr. 20, 2018 and entitledSYSTEM, METHOD AND PROGRAM PRODUCT FOR GENERATING AND UTILIZING STABLEVALUE DIGITAL ASSETS, and U.S. Provisional Patent Application Ser. No.62/647,353, filed on Mar. 23, 2018 and entitled SYSTEM, METHOD ANDPROGRAM PRODUCT FOR GENERATING AND UTILIZING STABLE VALUE DIGITAL ASSETSand U.S. Provisional Patent Application Ser. No. 62/638,679, filed onMar. 5, 2018 and entitled SYSTEM, METHOD AND PROGRAM PRODUCT FORGENERATING AND UTILIZING STABLE VALUE DIGITAL ASSETS, the entire contentof each of which is hereby incorporated by reference herein. U.S.Non-Provisional patent application Ser. No. 16/280,788 also claimspriority as a continuation-in-part to U.S. Non-Provisional patentapplication Ser. No. 15/973,175, filed on May 7, 2018 and entitledSYSTEMS, METHODS, AND PROGRAM PRODUCTS FOR EXCHANGING DIGITAL ASSETS FORFIAT AND/OR OTHER DIGITAL ASSETS, which in turn claims priority to U.S.Provisional Patent Application No. 62/642,946, filed on Mar. 14, 2018and entitled SYSTEMS, METHODS, AND PROGRAM PRODUCTS FOR EXCHANGINGDIGITAL ASSETS FOR FIAT AND/OR OTHER DIGITAL ASSETS, and U.S.Provisional Patent Application No. 62/642,931 filed on Mar. 14, 2018 andentitled SYSTEMS, METHODS, AND PROGRAM PRODUCTS FOR EXCHANGING DIGITALASSETS FOR FIAT AND/OR OTHER DIGITAL ASSETS, and U.S. Provisional PatentApplication Ser. No. 62/629,417, filed Feb. 12, 2018 entitled SYSTEMS,METHODS, AND PROGRAM PRODUCTS FOR VERIFYING DIGITAL ASSETS HELD IN ACUSTODIAL DIGITAL ASSET WALLET, and U.S. Provisional Patent ApplicationSer. No. 62/660,655 filed on Apr. 20, 2018 and entitled SYSTEMS,METHODS, and PROGRAM PRODUCT FOR GENERATING AND UTILIZING STABLE VALUEDIGITAL ASSETS, the entire content of each of which is herebyincorporated by reference herein. U.S. Non-Provisional patentapplication Ser. No. 16/280,788 also claims priority as acontinuation-in-part to U.S. Non-Provisional patent application Ser. No.15/920,042, filed on Mar. 13, 2018 and entitled SYSTEMS, METHODS, ANDPROGRAM PRODUCTS FOR VERIFYING DIGITAL ASSETS HELD IN A CUSTODIALDIGITAL ASSET WALLET, which in turn claims priority to U.S. ProvisionalPatent Application No. 62/629,417 filed Feb. 12, 2018 and entitledSYSTEMS, METHODS, AND PROGRAM PRODUCTS FOR VERIFYING DIGITAL ASSETS HELDIN A CUSTODIAL DIGITAL ASSET WALLET, the entire content of each of whichis hereby incorporated by reference herein.

FIELD

The present invention relates to a method, system, and program productrelating to modifying a supply of digital asset tokens on an underlyingblockchain.

BACKGROUND

In recent times, using blockchain technology and/or tokens to trackinventory, including potentially, equities or shares in a fund has beena subject of a lot of discussion. Moreover, the use of smart contractsto generate tokens on a blockchain have also become the subject of a lotof discussion.

However, current blockchain technology, as implemented, does not haveadequate technological solutions to provide for modifying a supply ofstable value digital asset tokens.

Accordingly, it would be beneficial to provide for a method, system andprogram product that provide for modifying a supply of stable valuedigital asset tokens using current blockchain technology and thus avoidthe problems discussed above.

SUMMARY

An object of the present invention is to address technologicalchallenges that currently exist in modifying a supply of stable valuedigital asset tokens tied to underlying blockchain technology associatedwith another digital asset.

This and other objects shall be addressed by embodiments of the presentinvention as set forth herein.

The present invention generally relates to a system, method and programproduct for modifying a supply stable value digital asset tokens tied toan underlying blockchain.

In embodiments, the present invention generally relates to the use ofstable value digital assets as a cryptocurrency that can be linked toother digital assets using blockchain technology. In embodiments, thepresent invention relates to specific applications of stable valuedigital asset tokens tied to a blockchain.

A stable value digital asset token (e.g., SVCoin) is provided which maybe pegged to a fiat currency such as USD, Euro, Yen, to name a few. Forexample, 1 SVCoin will have a net asset value (“NAV”) of $1 USD. Inembodiments, 100 SVCoins may have a NAV of $1 USD, so that 1 SVCoin hasa NAV of 1 penny. Unlike Bitcoin and many other crypto protocols, theSVCoin will not have a natural cap (e.g., 22 million bitcoins) and,because it is pegged to a fiat currency, it will not fluctuate in valueagainst such fiat currency as is typical of many crypto currencies.

In embodiments, the SVCoin can be issued by a trusted entity, like adigital asset exchange, bank, or other trusted entity using a token onan established blockchain, like ether or bitcoin, and smart contracttechnology. Thus, for example, a buyer can provide the trusted entity(e.g., digital asset exchange, bank, etc.) with a fixed sum of fiat(e.g., 50 USD) and in return be issued a corresponding fixed sum ofSVCoin (e.g., 50 SVCoin). In embodiments, the digital asset exchange canbe a regulated trust, such as Gemini Trust Company LLC (“Gemini”). Inembodiments, other types of trusted entities (e.g., banks, trusts, etc.)may also be used to issue, administer, redeem, and/or otherwise managethe SVCoin. In embodiments, the trusted entity (digital asset exchange,bank, etc.) can charge a processing fee for issuing the SVCoin either infiat or in a digital asset, such as the SVCoin. In embodiments, fiatdeposited to the trusted entity (e.g., digital asset exchange) ismaintained by the trusted entity on par with the amounts deposited.Thus, in embodiments, SVCoin is collateralized by fiat. SVCoin holderscan also exchange SVCoin for fiat on the same notional basis with thetrusted entity.

In embodiments, a method of increasing a total supply of digital assettokens including the steps of: (a) providing a first designated keypair, including a first designated public key and a corresponding firstdesignated private key, wherein the first designated public key alsocorresponds to a first designated public address associated with anunderlying digital asset; wherein the underlying digital asset ismaintained on a distributed public transaction ledger maintained in theform of a blockchain by a plurality of geographically distributedcomputer systems in a peer-to-peer network in the form of a blockchainnetwork, and wherein the first designated private key is stored on afirst computer system which is connected to the distributed publictransaction ledger through the Internet; (b) providing a seconddesignated key pair, including a second designated public key and acorresponding second designated private key, wherein the seconddesignated public key also corresponds to a first designated publicaddress associated with the underlying digital asset; wherein the seconddesignated private key is stored on a second computer system which isphysically separated from the first computer system and is notoperatively or physically connected to the distributed publictransaction ledger or the Internet; (c) providing first smart contractinstructions associated with a first smart contract associated with adigital asset token associated with a first contract address associatedwith the blockchain associated with the underlying digital asset,wherein the first smart contract instructions are saved as part of theblockchain for the underlying digital asset and include: (1) firstdelegation instructions to delegate one or more first functionsassociated with the digital asset token to one or more delegatedcontract addresses associated with the blockchain associated with theunderlying digital asset, wherein the one or more delegated contractaddresses are different from the first contract address, and wherein asecond contract address is designated as one of the one or moredelegated contract addresses; (2) first authorization instructionsassociated with the second designated key pair; (d) providing secondsmart contract instructions associated with a second smart contractassociated with the digital asset token associated with the secondcontract address associated with the blockchain associated with theunderlying digital asset, wherein the second smart contract instructionsare saved as part of the blockchain for the underlying digital assetsand include: (1) print limiter token creation instructions indicatingconditions under which tokens of the digital asset token are created;(2) second authorization instructions to create tokens of the digitalasset token, wherein the first designated key pair is designated toauthorize said second authorization instructions to create tokens of thedigital asset token; (3) third authorization instructions with respectto token creation of the digital asset token; wherein the thirdauthorization instructions designate a first designated custodianaddress with respect to token creation of the digital asset token; (e)providing third smart contract instructions associated with a firstdesignated custodian contract associated with the digital asset tokenassociated with a third contract address associated with the blockchainassociated with the underlying digital asset, wherein the third contractaddress is the first designated custodian contract address, and whereinthe third smart contract instructions are saved as part of theblockchain for the underlying digital assets and include: (1) fourthauthorization instructions to authorize issuance of instructions to thesecond smart contract regarding token creation; wherein the fourthauthorization instructions designate the second designated key pair toauthorize the fourth authorization instructions; (f) providing fourthsmart contract instructions associated with a fourth smart contractassociated with the digital asset token associated with a fourthcontract address associated with the blockchain associated with theunderlying digital asset, wherein the fourth contract address is one ofthe one or more delegated contract addresses and not: (i) the firstcontract address, (ii) the second contract address, or (iii) the thirdcontract address, wherein the fourth smart contract instructions aresaved as part of the blockchain associated with the underlying digitalassets and include: (1) token creation instructions to create tokens ofthe digital asset tokens in accordance with conditions set forth by theprint limiter token creation instructions; (2) second delegationinstructions delegating data storage operations to at least a fifthcontract address; (g) providing fifth smart contract instructionsassociated with a fifth smart contract associated with the digital assettoken associated with the fifth contract address associated with theblockchain associated with the underlying digital asset, wherein thefifth contract address is one of one or more designated store contractaddresses, and wherein the fifth smart contract instructions are savedas part of the blockchain for the underlying digital assets and include:(1) data storage instructions for transaction data related to thedigital asset token, wherein the transaction data includes for allissued tokens of the digital asset token: (A) respective public addressinformation associated with the blockchain associated with theunderlying digital asset; and (B) corresponding respective token balanceinformation associated with said respective public address information;(2) fifth authorization instructions to modify the transaction data inresponse to a request from the fourth contract address; (h) increasingthe total supply of the digital asset tokens, by a digital asset tokenissuer system, from a first amount of the digital asset tokens to asecond amount of the digital asset tokens, including the steps of: (1)generating, by the digital asset token issuer system, a firsttransaction request including a first message including a first requestto increase the total supply of the digital asset tokens to the secondamount of digital asset tokens, to the fourth contract address, whereinthe first transaction request is digitally signed by the firstdesignated private key; (2) sending, by the digital asset token issuersystem via the blockchain network, the first transaction request fromthe first designated public address to the fourth contract address; (3)sending, by the digital asset token issuer system via the blockchainnetwork, the first transaction request from the fourth contract addressto the second contract address; wherein the second smart contractexecutes, via the plurality of geographically distributed computersystems in the peer-to-peer network with reference to the blockchain,the first transaction request to return a first unique lock identifierassociated with the first transaction request; (4) obtaining, by thedigital asset token issuer system, the first unique lock identifier,based on reference to the blockchain; (5) generating, by the digitalasset token issuer system, a second transaction request including asecond message including a second request to unlock the total supply ofthe digital asset tokens in accordance with the first request andincluding the first unique lock identifier, wherein the secondtransaction request being to the third contract address, and digitallysigned by the first designated private key; (6) sending, by the digitalasset token issuer system via the blockchain network, the secondtransaction request from the first designated public address to thethird contract address, wherein the third smart contract executes, viathe plurality of geographically distributed computer systems in thepeer-to-peer network with reference to the blockchain, the secondtransaction request to return a first unique request hash associatedwith the second transaction request; (7) obtaining, by the digital assettoken issuer system, the first unique request hash, based on referenceto the blockchain; (8) generating, by the digital asset token issuersystem, a third transaction request to be digitally signed by at leastthe second designated private key including the first unique requesthash; (9) transferring, from the digital asset token issuer system to afirst portable memory device, the third transaction request; (10)transferring, from the first portable memory device to the secondcomputer system, the third transaction request; (11) digitally signing,by the second computer system, the third transaction request using thesecond designated private key to generate a third digitally signedtransaction request; (12) sending, from the second portable memorydevice using the digital asset token issuer system, via the blockchainnetwork, the third digitally signed transaction request to the thirdcontract address; wherein the third smart contract, executes, via theplurality of geographically distributed computer systems in thepeer-to-peer network with reference to the blockchain, the thirddigitally signed transaction request to validate the second request tounlock based on the third digitally signed transaction request and thefirst unique request hash and executes a first call to the secondcontract address, to increase the total supply of the digital assettokens to the second amount of digital asset tokens, wherein the secondcontract address returns the first call to the fourth contract addressand the fourth smart contract executes, via the plurality ofgeographically distributed computer systems in the peer-to-peer networkwith reference to the blockchain, a second call to the fifth contractaddress to set the total supply of the digital asset tokens to thesecond amount of digital asset tokens, wherein the fifth smart contractexecutes, via the plurality of geographically distributed computersystems in the peer-to-peer network with reference to the blockchain,the second call to set the total supply of the digital asset tokens tothe second amount of digital asset tokens; and (i) confirming, by thedigital asset token issuer system, the total supply of digital assettokens is set to the second amount of digital asset tokens based onreference to the blockchain.

In embodiments, the first designated key pair includes an additionaldesignated key pair including a first additional designated public keyand a corresponding first additional designated private key, wherein thefirst additional designated public key also corresponds to a firstadditional designated public address associated with the underlyingdigital asset.

In embodiments, the second computer system is a hardware storage module.In embodiments, the second designated key set includes an additionaldesignated key set including a second additional designated publicaddress and a second additional designated private key.

In embodiments, the second authorization instructions for the firstdesignated key set with respect to token creation of the digital assettoken includes instructions limiting creation of digital asset tokensabove a first threshold amount over a first period of time.

In embodiments, the fourth authorization instructions includeinstructions to permit creation of digital asset tokens above the firstthreshold during the first period of time, wherein the fourthauthorization instructions designate the second designated key pair toauthorize the instructions to permit creation of digital asset tokensabove the first threshold.

In embodiments, the third smart contract instructions further include:(2) sixth authorization instructions to designate a seventh contractaddress as one of the one or more delegated contract addresses, whereinthe seventh contract address is not the second contract address, andwherein the second designated key pair is designated to authorize thesixth authorization instructions.

In embodiments, the fourth smart contract instructions further include:(3) token transfer instructions related to transferring issued tokens ofthe digital asset token from a first designated contract address to asecond designated contract address. In embodiments, the fourth smartcontract instructions further include: (3) token destructioninstructions related to destroying one or more issued token of thedigital asset token. In embodiments, the fourth smart contractinstructions further include: (3) token transfer instructions related totransferring issued tokens of the digital asset token from a firstdesignated contract address to a second designated contract address; and(4) token destruction instructions related to destroying one or moreissued tokens of the digital asset token.

In embodiments, the second smart contract instructions further include:(4) token balance modification instructions related to modifying thetotal balance of tokens of the digital asset token assigned to a thirddesignated address.

In embodiments, the first transaction request includes first transactionfee information for miners associated with the plurality ofgeographically distributed computer systems in the peer-to-peer networkto process the first transaction request. In embodiments, the secondtransaction request includes second transaction fee information forminers associated with the plurality of geographically distributedcomputer systems in the peer-to-peer network to process the secondtransaction request.

In embodiments, the first portable memory device includes the secondportable memory device.

In embodiments, the second smart contract instructions include sixthauthorization instructions to modify the total token supply amount ofthe digital asset tokens.

In embodiments, the underlying digital asset is a stable value token. Inembodiments, the underlying digital asset is Neo. In embodiments, theunderlying digital asset is Ether. In embodiments, the underlyingdigital asset is Bitcoin.

In embodiments, the first designated private key is mathematicallyrelated to a first designated public key.

In embodiments, the first designated public address includes the firstdesignated public key.

In embodiments, the first designated public address includes a hash ofthe first designated public key.

In embodiments, the first designated public address includes a partialhash of the first designated public key.

In embodiments, the second designated private key is mathematicallyrelated to a second designated public key.

In embodiments, the second designated public address includes the seconddesignated public key.

In embodiments, the second designated public address includes a hash ofthe second designated public key.

In embodiments, the second designated public address includes a partialhash of the second designated public key.

In embodiments, a method of increasing a total supply of digital assettokens including the steps of: (a) providing a first designated keypair, including a first designated public key and a corresponding firstdesignated private key, wherein the first designated public key alsocorresponds to a first designated public address associated with anunderlying digital asset; wherein the underlying digital asset ismaintained on a distributed public transaction ledger maintained in theform of a blockchain by a plurality of geographically distributedcomputer systems in a peer-to-peer network in the form of a blockchainnetwork, and wherein the first designated private key is stored on afirst computer system which is connected to the distributed publictransaction ledger through the Internet; (b) providing a seconddesignated key pair, including a second designated public key and acorresponding second designated private key wherein the seconddesignated public key also corresponds to a second designated publicaddress associated with the underlying digital asset, wherein the seconddesignated private key is stored on a second computer system which isphysically separated from the first computer system and is notoperatively or physically connected to the distributed publictransaction ledger or the Internet; (c) providing first smart contractinstructions associated with a first smart contract associated with adigital asset token associated with a first contract address associatedwith the blockchain associated with the underlying digital asset,wherein the first smart contract instructions are saved as part of theblockchain for the underlying digital assets and include: firstdelegation instructions to delegate one or more first functionsassociated with the digital asset token to one or more delegatedcontract addresses associated with the blockchain associated with theunderlying digital asset, wherein the one or more delegated contractaddresses is different from the first contract address, and wherein asecond contract address is designated as one of the one or moredelegated contract addresses; (1) first authorization instructions forthe second designated key pair; (d) providing second smart contractinstructions associated with a second smart contract associated with thedigital asset token associated with the second smart contract addressassociated with the blockchain associated with the underlying digitalasset, wherein the second smart contract instructions are saved as partof the blockchain for the underlying digital asset and include: (1)print limiter token creation instructions indicating conditions underwhich tokens of the digital asset token are created; (2) secondauthorization instructions to create tokens of the digital asset token,wherein the first designated key pair is designated to authorize saidsecond authorization instructions to create tokens of the digital assettoken; and (3) third authorization instructions with respect to tokencreation of the digital asset token; wherein the third authorizationinstructions designate a first designated custodian address with respectto token creation of the digital asset token; (e) providing third smartcontract instructions associated with a first designated custodian smartcontract associated with the digital asset token associated with a thirdcontract address associated with the blockchain associated with theunderlying digital asset, wherein the third contract address is thefirst designated custodian contract address, and wherein the third smartcontract instructions are saved as part of the blockchain associatedwith the underlying digital asset and include: fourth authorizationinstructions to authorize issuance of instructions to the second smartcontract regarding token creation; wherein the fourth authorizationinstructions designate the second designated key pair to authorize thefourth authorization instructions; providing fourth smart contractinstructions associated with a fourth smart contract associated with thedigital asset token associated with a fourth contract address associatedwith the blockchain associated with the underlying digital asset,wherein the fourth contract address is one of the one or more delegatedcontract addresses and not: (i) the first contract address, (ii) thesecond contract address, or (iii) the third contract address, whereinthe fourth smart contract instructions are saved as part of theblockchain associated with the underlying digital assets and include:(1) token creation instructions to create tokens of the digital assettoken in accordance with conditions set forth by the print limiter tokencreation instructions; and (2) second delegation instructions delegatingdata storage operations to at least a fifth contract address; (f)providing fifth smart contract instructions associated with a fifthsmart contract associated with the digital asset token associated withthe fifth contract address associated with the blockchain associatedwith the underlying digital asset, wherein the fifth smart contractaddress is one of the one or more designated store contract addresses,and wherein the fifth smart contract instructions are saved as part ofthe blockchain for the underlying digital assets and include: (1) datastorage instructions for transaction data related to the digital assettoken, wherein said transaction data includes for all issued tokens ofthe digital asset token: (A) respective public address informationassociated with the blockchain associated with the underlying digitalasset; and (B) corresponding respective token balance informationassociated with said respective public address information; (1) fifthauthorization instructions to modify the transaction data in response torequests from the fourth contract address; (g) receiving, by a digitalasset token issuer system, a request to generate and assign to the firstdesignated public address a first amount of digital asset tokens; (h)generating, by the digital asset token issuer system, the first amountof digital asset tokens and assigning said first amount of digital assettokens to the first designated public address increasing the totalsupply of the digital asset tokens, including the steps of: (1)generating, by the digital asset token issuer system, and sending, usingthe digital asset token issuer system via the blockchain network, afirst transaction request: (A) to the fourth contract address; and (B)including a first message including a first request to generate thefirst amount of digital asset tokens and assign said first amount ofdigital asset tokens to the first designated public address; wherein thefirst transaction request is digitally signed by the first designatedprivate key; wherein the fourth smart contract executes, via theplurality of geographically distributed computer systems in thepeer-to-peer network with reference to the blockchain, the firsttransaction request to: (i) validate the first request and the authorityof the first designated private key to call the second smart contract toexecute the first request; and (ii) send a first call to the fourthcontract address to generate and assign to the first designated publicaddress the first amount of digital asset tokens; wherein the fourthsmart contract executes, via the plurality of geographically distributedcomputer systems in the peer-to-peer network with reference to theblockchain, the first call to generate a first unique lock identifier,and return to the second smart contract address, the first unique lockidentifier; wherein, in response to the return of the first unique lockidentifier, the second smart contract executes, via the plurality ofgeographically distributed computer systems in the peer-to-peer networkwith reference to the blockchain, a call to the fourth smart contractaddress to confirm the first call with the first lock identifier;wherein, in response, the fourth smart contract executes, via theplurality of geographically distributed computer systems in thepeer-to-peer network with reference to the blockchain, the first call toexecute a second call to the fifth contract address to obtain the totalsupply of digital asset tokens in circulation; wherein, in response, thefifth smart contract executes, via the plurality of geographicallydistributed computer systems in the peer-to-peer network with referenceto the blockchain, the second call and returns, to the fourth contractaddress, a second amount of digital asset tokens corresponding to thetotal supply of digital asset tokens in circulation; wherein, inresponse to the return of the second amount, the fourth smart contract,executes via the plurality of geographically distributed computersystems in the peer-to-peer network with reference to the blockchain, athird call request to the fifth contract address to set a new totalsupply of digital asset tokens in circulation to a third amount, whichis the total of the first amount and the second amount; wherein, inresponse to the third call, the fifth smart contract, executes via theplurality of geographically distributed computer systems in thepeer-to-peer network with reference to the blockchain, the third calland sets a new total supply of digital asset tokens in circulation atthe third amount; wherein, the fourth smart contract executes, via theplurality of geographically distributed computer systems in thepeer-to-peer network with reference to the blockchain, a fourth call tothe fifth contract address to add the first amount of digital assettokens to a respective balance associated with the first designatedpublic address; wherein, in response, the fifth smart contract executes,via the plurality of geographically distributed computer systems in thepeer-to-peer network with reference to the blockchain, the fourth callto set the balance of digital asset tokens in the first designatedpublic address at a fourth amount which includes the addition of thefirst amount to the previous balance; and (i) confirming, by the digitalasset token issuer system, that the balance of digital asset tokensassociated with the first designated public address is set to includethe first amount of digital asset tokens based on reference to theblockchain.

In embodiments, the second computer system is a hardware storage module.

In embodiments, the second designated key set includes an additionaldesignated key set including an additional designated public address andan additional designated private key.

In embodiments, the second authorization instructions for the firstdesignated key set with respect to token creation of the digital assettoken include instruction limiting token creation above a firstthreshold over a first period of time. In embodiments, the fourthauthorization instructions for the second designated key set toauthorize the issuance of instructions to the second smart contractinstructions with respect to token creation include instructions toallow for creation of digital asset tokens above the first thresholdduring the first period of time. In embodiments, the third smartcontract instructions further include: (2) sixth authorizationinstructions to designate a seventh contract address as one of the oneor more delegated contract addresses, wherein the seventh contractaddress is not the second contract address, and wherein the seconddesignated key set is designated to authorize the sixth authorizationinstructions.

In embodiments, the fourth smart contract instructions further include:(3) token transfer instructions related to transferring tokens of thedigital asset token from a first designated contract address to a seconddesignated contract address. In embodiments, the fourth smart contractinstructions further include: (3) token destruction instructions relatedto destroying one or more digital asset token. In embodiments, thefourth smart contract instructions further include: (3) token balancemodification instructions related to modifying a total number of tokensof the digital asset token assigned to a third designated publicaddress. In embodiments, the fourth smart contract instructions furtherinclude: (3) token transfer instructions related to transferring tokensof the digital asset token from a first designated contract address to asecond designated contract address; and (4) token destructioninstructions related to destroying one or more tokens of the digitalasset token.

In embodiments, the method further includes receiving, prior togenerating the first amount of digital asset tokens, a validatingrequest. In embodiments, the method further includes determining thefirst designated key set has authority to process the request togenerate the first amount of digital tokens.

In embodiments, the first transaction request includes first transactionfee information for miners in the plurality of geographicallydistributed computer systems in the peer-to-peer network to process thefirst transaction request.

In embodiments, the fifth contract returns the balance of digital assettokens to the fourth smart contract address. In embodiments, the fifthcontract returns the balance of digital asset tokens to the second smartcontract address.

In embodiments, the method further includes the steps of: (k) receiving,by the plurality of geographically distributed computer systems in thepeer-to-peer network, from a first user device associated with the firstdesignated public address, via the underlying blockchain, a secondtransaction request: (A) from the first designated public address; (B)to the first contract address; and (C) including a second messageincluding a second request to transfer a fifth amount of digital assetsfrom the first designated public address to a third designated publicaddress; wherein the first transaction request is digitally signed bythe first designated private key, which is mathematically related to thefirst designated public address; wherein the first user device hadaccess to the first designated private key prior to sending the secondtransaction request; wherein the first smart contract executes, via theplurality of geographically distributed computer systems in thepeer-to-peer network, the second transaction request to execute, via theplurality of geographically distributed computer systems in thepeer-to-peer network, a sixth call request to the fourth contractaddress to transfer a fifth amount of digital assets from the firstdesignated public address to the third designated public address;wherein, in response to the sixth call request, the fourth smartcontract, executes via the plurality of geographically distributedcomputer systems in the peer-to-peer network, sixth authorizationinstructions to verify the sixth call came from an authorized contractaddress, and upon verification, to execute a seventh call request to thefifth contract address to obtain a sixth amount of digital asset tokenswhich reflect a current balance of digital asset tokens associated withthe first designated public address; wherein, in response to the seventhcall request, the fifth smart contract, executes via the plurality ofgeographically distributed computer systems in the peer-to-peer network,the seventh call request to return the sixth amount of digital assettokens; wherein, in response to the return of the sixth amount ofdigital asset, the fourth smart contract executes, via the plurality ofgeographically distributed computer systems in the peer-to-peer network:(1) a balance verification instruction to confirm that the fifth amountof digital asset tokens is less than or equal to the sixth amount ofdigital asset tokens, and (2) in the case where the fifth amount ofdigital asset tokens is less than or equal to the sixth amount ofdigital asset tokens, execute, via the plurality of geographicallydistributed computer systems in the peer-to-peer network, a seventh callrequest to the fifth contract address to set a new balance for thedigital asset tokens in the first designated public address to a seventhamount which equals the sixth amount less the fifth amount; wherein, inresponse to the seventh call, the fifth smart contract executes, via theplurality of geographically distributed computer systems in thepeer-to-peer network, the seventh call to set and store the new balancefor the first designated public address as the seventh amount andreturns a new balance for the first designated public address as theseventh amount; wherein, in response to the return of the new balance,the fourth smart contract executes, via the plurality of geographicallydistributed computer systems in the peer-to-peer network, an eighth callto add the second amount of digital asset tokens to the balanceassociated with the third designated public address; wherein, inresponse to the eighth call request, the fifth smart contract executes,via the blockchain network, the eighth call request to set the balanceof digital asset tokens associated with the third designated publicaddress at a seventh amount which includes the addition of the secondamount to a previous balance associated with the third designated publicaddress; and wherein the first user device confirms that the balance ofdigital asset tokens associated with the first designated public addressis the sixth amount of digital asset tokens based on reference to theblockchain.

In embodiments, the second transaction request includes secondtransaction fee information for miners in the plurality ofgeographically distributed computer systems in the peer-to-peer networkto process the second transaction request. In embodiments, the balanceof digital asset tokens associated with the third designated publicaddress is returned to the fourth contract address. In embodiments, thebalance of digital asset tokens associated with the third public addressis returned to the first smart contract address. In embodiments, asecond user device confirms that the balance of the digital asset tokensassociated with the third designated public address is the seventhamount of digital asset tokens based on reference to the blockchain.

In embodiments, the method further includes the steps of: (k) providinga third designated key set, including a third designated public addressassociated with the underlying digital asset and a corresponding thirddesignated private key, and wherein the third designated private key isstored on a third computer system which is connected to the distributedpublic transaction ledger through the Internet; and (l) receiving, bythe plurality of geographically distributed computer systems in thepeer-to-peer network, from the third computer system, via theblockchain, a second transaction request: (A) from the third designatedpublic key address; (B) to the fifth contract address; and (C) includinga second message including a request to burn a fifth amount of digitalasset tokens from a balance associated with the third designated publicaddress; wherein the second transaction request is digitally signed bythe third designated private key; wherein the fourth smart contractexecutes, via the plurality of geographically distributed computersystems in the peer-to-peer network, the second transaction request toexecute, via the plurality of geographically distributed computersystems in the peer-to-peer network, a sixth call request to the fifthcontract address to obtain a sixth amount of digital asset tokens whichreflect a current balance of digital asset tokens associated with thethird designated public address; wherein, in response to the sixth callrequest, the fifth smart contract, executes via the plurality ofgeographically distributed computer systems in the peer-to-peer network,the seventh call request to return the sixth amount of digital assettokens; wherein, in response to the return of the sixth amount ofdigital asset, the fourth smart contract executes, via the plurality ofgeographically distributed computer systems in the peer-to-peer network:(1) a balance verification instruction to confirm that the fifth amountof digital asset tokens is less than or equal to the sixth amount ofdigital asset tokens; and (2) in the case where the fifth amount ofdigital asset tokens is less than or equal to the sixth amount ofdigital asset tokens, execute, via the plurality of geographicallydistributed computer systems in the peer-to-peer network, a seventh callrequest to the fifth contract address to set a new balance for thedigital asset tokens associated with the third designated public keyaddress to a seventh amount which equals the sixth amount less the fifthamount; wherein, in response to the seventh call, the fifth smartcontract executes, via the plurality of geographically distributedcomputer systems in the peer-to-peer network, the seventh call to setand store the new balance for the third designated public key address asthe seventh amount and returns the new balance for the third designatedpublic key address as the seventh amount; wherein, in response to thereturn of the new balance, the fourth smart contract executes, via theblockchain network, an eighth call request to the fifth contract addressto obtain a total supply of digital asset tokens in circulation;wherein, in response to the eighth call request, the fifth smartcontract executes, via the plurality of geographically distributedcomputer systems in the peer-to-peer network, the eighth call requestand returns, to the fourth contract address, an eighth amount of digitalasset tokens corresponding to the total supply of digital asset tokensin circulation; wherein, in response to the return of the eighth amount,the fourth smart contract, executes via the plurality of geographicallydistributed computer systems in the peer-to-peer network, a ninth callrequest to the fifth contract address to set a new total supply ofdigital asset tokens in circulation to a ninth amount, which is theeighth amount less the fifth amount; and wherein, in response to theninth call request, the fifth smart contract, executes via theblockchain network, the ninth call request and sets a new total supplyof digital asset tokens in circulation at the ninth amount, and returnsto the fourth contract address.

In embodiments, the third designated key set is the first designated keyset. In embodiments, the third designated key set is not the seconddesignated key set. In embodiments, the third designated key set is thesecond designated key set. In embodiments, the third designated key setis not the first designated key set. In embodiments, the third computersystem is the first computer system. In embodiments, the third computersystem is not the first computer system. In embodiments, theadministrator computer system includes the first computer system and thethird computer system. In embodiments, the administrator computer systemincludes the first computer system and the second computer system.

In embodiments, the underlying digital asset is a stable value token. Inembodiments, the underlying digital asset is Neo. In embodiments, theunderlying digital asset is Ether. In embodiments, the underlyingdigital asset is Bitcoin.

In embodiments, the first designated private key is mathematicallyrelated to a first designated public key.

In embodiments, wherein the first designated public address includes thefirst designated public key.

In embodiments, the first designated public address includes a hash ofthe first designated public key.

In embodiments, the first designated public address includes a partialhash of the first designated public key.

In embodiments, the second designated private key is mathematicallyrelated to a second designated public key.

In embodiments, the second designated public address includes the seconddesignated public key.

In embodiments, the second designated public address includes a hash ofthe second designated public key.

In embodiments, the second designated public address includes a partialhash of the second designated public key.

In embodiments, the second smart contract instructions include sixthauthorization instructions related to modifying a token supply of thedigital asset token.

A method of increasing a total supply of digital asset tokens includesin accordance with an embodiment of the present application includes thesteps of:(a) providing a first designated key pair, comprising a firstdesignated public key of an underlying digital asset and a correspondingfirst designated private key, wherein the underlying digital asset ismaintained on a distributed public transaction ledger maintained by aplurality of geographically distributed computer systems in apeer-to-peer network in the form of a blockchain, and wherein the firstdesignated private key is stored on a first computer system which isconnected to the distributed public transaction ledger through theInternet; (b)providing a second designated key pair, comprising a seconddesignated public key of the underlying digital asset and acorresponding second designated private key, wherein the seconddesignated private key is stored on a second computer system which isphysically separated from the first computer system and is notoperatively or physically connected to the distributed publictransaction ledger or the Internet; (c) providing first smart contractinstructions for a digital asset token associated with a first contractaddress associated with the blockchain associated with the underlyingdigital asset, wherein the first smart contract instructions are savedin the blockchain for the underlying digital assets and include: (1)first delegation instructions to delegate one or more first functionsassociated with the digital asset token to one or more delegatedcontract addresses associated with the blockchain associated with theunderlying digital asset, wherein the one or more delegated contractaddresses is different from the first contract address; (2) firstauthorization instructions for the second designated key pair; (d)providing second smart contract instructions for the digital asset tokenassociated with a second contract address associated with the blockchainassociated with the underlying digital asset, which is one of the one ormore delegated contract addresses and not the first contract address,wherein the second smart contract instructions are saved in theblockchain for the underlying digital assets and include: (1) printlimiter token creation instructions indicating conditions under whichtokens of the digital asset token are created; (2) second authorizationinstructions for the first designated key pair with respect to tokencreation of the digital asset token; (3) third authorizationinstructions for a first designated custodian address with respect totoken creation of the digital asset token; (e) providing third smartcontract instructions for the digital asset token associated with athird contract address associated with the blockchain associated withthe underlying digital asset, which is the first designated custodiancontract address, wherein the third smart contract instructions aresaved in the blockchain for the underlying digital assets and include:(1) fourth authorization instructions for the second designated key pairwith respect to authorizing the issuance of instructions to the secondsmart contract regarding token creation; (f) providing fourth smartcontract instructions for the digital asset token associated with afourth contract address associated with the blockchain associated withthe underlying digital asset, which is one of the one or more delegatedcontract addresses and not the first contract address, second contractaddress or third contract address, wherein the fourth smart contractinstructions are saved in the blockchain for the underlying digitalassets and include: (1) token creation instructions to create tokens ofthe digital asset tokens under conditions set forth by the print limitertoken creation instructions; (2) second delegation instructions fordelegating to another contract address, data storage operations; (g)providing fifth smart contract instructions for the digital asset tokenassociated with a fifth contract address associated with the blockchainassociated with the underlying digital asset, which is one of the one ormore designated store contract addresses, wherein the fifth smartcontract instructions are saved in the blockchain for the underlyingdigital assets and include: (1) data storage instructions fortransaction data related to the digital asset token, wherein saidtransaction data comprises for all issued tokens of the digital assettoken: (A) public address information associated with the underlyingdigital asset; and (B) corresponding token balance informationassociated with said public address information; (2) fifth authorizationinstructions for modifying the transaction data in response to a requestfrom the fourth contract address; (h) increasing the total supply of thedigital asset token, by a digital asset token issuer system, from afirst amount of the digital asset tokens to a second amount of thedigital asset tokens, comprising the steps of: (1) generating, by thedigital asset token issuer system, a first transaction request includinga first message comprising a first request to increase the total supplyof the digital asset token to a second amount of digital asset tokens,from the on-line public key address to the fourth contract address,wherein the first transaction request is digitally signed by the firston-line private key; (2) sending, by the digital asset token issuersystem via the underlying blockchain, the first transaction request fromthe on-line public key address to the fourth contract address; (3)sending, by the digital asset token issuer system via the underlyingblockchain, the first transaction request from the fourth contractaddress to the second contract address; wherein the second smartcontract executes, via the blockchain network, the first transactionrequest to return a first unique lock identifier associated with thefirst transaction request; (4) obtaining, by the digital asset tokenissuer system, the first unique lock identifier, based on reference tothe blockchain; (5) generating, by the digital asset token issuersystem, a second transaction request including a second messagecomprising a second request to unlock the total supply of the digitalasset token in accordance with the first request and including the firstunique lock identifier, the second transaction request being from theon-line public key address to the third contract address, wherein thesecond transaction request is digitally signed by the first on-lineprivate key; (6) sending, by the digital asset token issuer system viathe underlying blockchain, the second transaction request from theon-line public key address to the third contract address; wherein thethird smart contract executes, via the blockchain network, the secondtransaction request to return a first unique request hash associatedwith the second transaction request; (7) obtaining, by the digital assettoken issuer system, the first unique request hash, based on referenceto the blockchain; (8) generating, by the digital asset token issuersystem, a third transaction request to be digitally signed by at leastthe second designated private key including the first unique requesthash; (9) transferring, from the digital asset token issuer system to afirst portable memory device, the third transaction request; (10)transferring, from the first portable memory device to the secondcomputer system, the third transaction request; (11) digitally signing,by the second computer system, the third transaction request using thesecond designated private key to generate a third digitally signedtransaction request; (12) sending, from the second portable memorydevice using the digital asset token issuer system, via the underlyingblockchain, the third digitally signed transaction request to the thirdcontract address; and (i) confirming, by the digital asset token issuersystem, that the total supply of digital asset tokens is set to thesecond amount of digital asset tokens based on reference to theblockchain; wherein the third smart contract, executes, via theblockchain network, the third digitally signed transaction request tovalidate the second request to unlock based on the third digitallysigned transaction request and the first unique request hash andexecutes a first call to the second contract address, to increase thetotal supply of the digital asset token to the second amount of digitalasset tokens, wherein the second contract address returns the first callto the fourth contract address and the fourth smart contract executes,via the blockchain network, a second call to the fifth contract addressto set the total supply of the digital asset tokens to the second amountof digital asset tokens, wherein the fifth smart contract executes, viathe blockchain, the second call to set the total supply of the digitalasset tokens to the second amount of digital asset tokens.

In embodiments, the first designated key pair includes an additionaldesignated key pair comprising an additional designated public key andan additional designated private key.

In embodiments, the second computer system is a hardware storage module.

In embodiments, the second designated key pair comprises an additionaldesignated key pair comprising an additional designated public key andan additional designated private key.

In embodiments, the second authorization instructions for the firstdesignated key pair with respect to token creation of the digital assettoken includes instructions limiting creation of digital asset tokensabove a first threshold amount over a first period of time.

In embodiments, the fourth authorization instructions for the seconddesignated key pair to authorize the issuance of instructions to thesecond smart contract instructions with respect to token creationincludes instructions to permit creation of digital asset tokens abovethe first threshold during the first period of time.

In embodiments, the third smart contract instructions further include:(2) sixth authorization instructions for the second designated key pairto authorize the issuance of instructions, to the first smart contract,to change the one or more designated contract addresses from the secondcontract address to a different designated contract address.

In embodiments, the fourth smart contract instructions further include:(3) token transfer instructions related to transferring tokens of thedigital asset token from a first designated contract address to a seconddesignated contract address.

In embodiments, the fourth smart contract instructions further include:(3) token destruction instructions related to destroying one or moretokens of the digital asset token.

In embodiments, the second smart contract instructions further include:(4) token balance modification instructions related to modifying a totalnumber of tokens of the digital asset token assigned to a thirddesignated address.

In embodiments, the fourth smart contract instructions further include:(3) token transfer instructions related to transferring tokens of thedigital asset token from a first designated contract address to a seconddesignated contract address; and (4) token destruction instructionsrelated to destroying one or more tokens of the digital asset token.

In embodiments, the first transaction request includes first transactionfee information for miners in the blockchain network to process thefirst transaction request.

In embodiments, the second transaction request includes secondtransaction fee information for miners in the blockchain network toprocess the second transaction request.

In embodiments, the first portable memory device includes the secondportable memory device.

In embodiments, the second smart contract instructions include sixthauthorization instructions related to modifying a token supply amount ofthe digital asset token.

A method of increasing a total supply of digital asset tokens inaccordance with an embodiment of the present application includes thesteps of: (a) providing a first designated key pair, comprising a firstdesignated public key of an underlying digital asset and a correspondingfirst designated private key, wherein the underlying digital asset ismaintained on a distributed public transaction ledger maintained by aplurality of geographically distributed computer systems in apeer-to-peer network in the form of the blockchain, and wherein thefirst designated private key is stored on a first computer system whichis connected to the distributed public transaction ledger through theInternet; (b) providing a second designated key pair, comprising asecond designated public key of the underlying digital asset and acorresponding second designated private key, wherein the seconddesignated private key is stored on a second computer system which isphysically separated from the first computer system and is notoperatively or physically connected to the distributed publictransaction ledger or the Internet; (c) providing first smart contractinstructions for a digital asset token associated with a first contractaddress associated with the blockchain associated with the underlyingdigital asset, wherein the first smart contract instructions are savedin the blockchain for the underlying digital assets and include: (1)first delegation instructions to delegate one or more first functionsassociated with the digital asset token to one or more delegatedcontract addresses associated with the blockchain associated with theunderlying digital asset, wherein the one or more delegated contractaddresses is different from the first contract address; and (2) firstauthorization instructions for the second designated key pair; (d)providing second smart contract instructions for the digital asset tokenassociated with a second contract address associated with the blockchainassociated with the underlying digital asset, which is one of the one ormore delegated contract addresses and not the first contract address,wherein the second smart contract instructions are saved in theblockchain for the underlying digital assets and include: (1) printlimiter token creation instructions indicating conditions under whichtokens of the digital asset token are created; (2) first custodianaddress information instructions associated with a first designatedcustodian; and (3) second authorization instructions for the firstdesignated key pair with respect to token creation of the digital assettoken; (e) providing third smart contract instructions for the digitalasset token associated with a third contract address associated with theblockchain associated with the underlying digital asset, which is thefirst designated custodian contract address, wherein the third smartcontract instructions are saved in the blockchain for the underlyingdigital assets and include: (1) fourth authorization instructions forthe second designated key pair with respect to issuance of instructionsto the second smart contract regarding token creation; (f) providingfourth smart contract instructions for the digital asset tokenassociated with a fourth contract address associated with the blockchainassociated with the underlying digital asset, wherein the fourth smartcontract instructions are saved in the blockchain for the underlyingdigital assets and include: (1) token creation instructions related tocreating tokens of the digital asset token under the conditions setforth by the print limiter token creation instructions; and (2) seconddelegation instructions for delegating to one or more designated storecontract addresses data storage functions; (g) providing fifth smartcontract instructions for the digital asset token associated with afifth contract address associated with the blockchain associated withthe underlying digital asset, which is one of the one or more designatedstored contract addresses, wherein the fifth smart contract instructionsare saved in the blockchain for the underlying digital assets andinclude: (1) data storage instructions for transaction data related tothe digital asset token, wherein said transaction data comprises for allissued tokens of the digital asset token: (A) public address informationassociated with the underlying digital asset; and (B) correspondingtoken balance information associated with said public addressinformation; (2) third custodian instructions associated with a thirddesignated custodian address corresponding to the fourth contractsaddress; and (3) fifth authorization instruction for modifying thetransaction data in response to requests from the fourth contractaddress; (h) receiving, by the digital asset token issuer system, arequest to generate and assign to a first designated public address afirst amount of digital tokens; (i) generating, by a digital asset tokenissuer system, the first amount of digital asset tokens and assigningsaid first amount of digital asset token to the first designated publicaddress increasing the total supply of the digital asset token,comprising the steps of: (1) generating, by the digital asset tokenissuer system, and sending, from the digital asset token issuer systemvia the underlying blockchain, a first transaction request: (A) from theon-line public key address; (B) to the fourth contract address; and (C)including a first message comprising a first request to generate thefirst amount of digital asset token and assign said first amount ofdigital asset tokens to the first designated public address; wherein thefirst transaction request is digitally signed by the first on-lineprivate key; wherein the fourth smart contract executes, via theblockchain network, the first transaction request to: (i) validate thefirst request and the authority of the first on-line private key to callthe second smart contract to execute the first request; and (ii) send afirst call to the fourth contract address to generate and assign to thefirst designated public address the first amount of digital assettokens; wherein the fourth smart contract executes, via the blockchainnetwork, the first call request to generate a first unique lockidentifier, and return to the second smart contract address the firstunique lock identifier; wherein, in response to the return of the firstunique lock identifier, the second smart contract executes, via theblockchain network, a call to the fourth smart contract address toconfirm the first call request with the first lock identifier; wherein,in response, the fourth smart contract executes, via the blockchainnetwork, the first call to execute a second call to the fifth contractaddress to obtain the total supply of digital asset tokens incirculation; wherein, in response, the fifth smart contract executes,via the blockchain network, the second call and returns, to the fourthcontract address, a second amount of digital asset tokens correspondingto the total supply of digital asset tokens in circulation; wherein, inresponse to the return of the second amount, the fourth smart contract,executes via the blockchain network, a third call request to the fifthcontract address to set a new total supply of digital asset tokens incirculation to a third amount, which is the total of the first amountand the second amount; wherein, in response to the third call, the fifthsmart contract, executes via the blockchain network, the third call andsets a new total supply of digital asset tokens in circulation at thethird amount; wherein, the fourth smart contract executes, via theblockchain network, a fourth call to the fifth contract address to addthe first amount of digital asset tokens to the balance associated withthe first designated public address; wherein, in response the fifthsmart contract executes, via the blockchain network, the fourth call toset the balance of digital asset tokens in the first designated publicaddress at a fourth amount which includes the addition of the firstamount to the previous balance; and (j)

confirming, by the digital asset token issuer system, that the balanceof digital asset tokens in the first designated public address is set toinclude the first amount of digital asset tokens based on reference tothe blockchain.

In embodiments, the second computer system is a hardware storage module.

In embodiments, the second designated key pair comprises an additionaldesignated key pair comprising an additional designated public key andan additional designated private key.

In embodiments, the second authorization instructions for the firstdesignated key pair with respect to token creation of the digital assettoken include instruction limiting token creation above a firstthreshold over a first period of time.

In embodiments, the fourth authorization instructions for the seconddesignated key pair to authorize the issuance of instructions to thesecond smart contract instructions with respect to token creationinclude instructions to allow for creation of digital asset tokens abovethe first threshold during the first period of time.

In embodiments, the third smart contract instructions further include:(2) sixth authorization instructions for the second designated key pairto authorize the issuance of instructions to the first smart contract tochange the one or more designated contract addresses from the secondcontract address to a different designated contract address.

In embodiments, the fourth smart contract instructions further include:(3) token transfer instructions related to transferring tokens of thedigital asset token from a first designated contract address to a seconddesignated contract address.

In embodiments, the fourth smart contract instructions further include:(3) token destruction instructions related to destroying one or moredigital asset token.

In embodiments, the fourth smart contract instructions further include:(3) token balance modification instructions related to modifying a totalnumber of tokens of the digital asset token assigned to a thirddesignated address.

In embodiments, the fourth smart contract instructions further include:(3) token transfer instructions related to transferring tokens of thedigital asset token from a first designated contract address to a seconddesignated contract address; and (4) token destruction instructionsrelated to destroying one or more tokens of the digital asset token.

In embodiments, the method further comprises receiving, prior togenerating the first amount of digital asset tokens, a validatingrequest.

In embodiments, the method further comprises determining the firstdesignated key pair has authority to process the request to generate thefirst amount of digital tokens.

In embodiments, the first transaction request includes first transactionfee information for miners in the blockchain network to process thefirst transaction request.

In embodiments, the fifth contract returns the balance of digital assettokens to the fourth smart contract address.

In embodiments, the fifth contract returns the balance of digital assettokens to the second smart contract address.

In embodiments, the method further comprises the steps of: (k)receiving, by the blockchain network, from a first user deviceassociated with the first designated public address, via the underlyingblockchain, a second transaction request: (A) from the first designatedpublic address; (B) to the first contract address; and (C) including asecond message comprising a second request to transfer a fifth amount ofdigital assets from the first designated public address to a seconddesignated public address; wherein the first transaction request isdigitally signed by a first private key, which is mathematically relatedto the first designated public address, and wherein the first userdevice had access to the first private key prior to sending the secondtransaction request; and wherein the first smart contract executes, viathe blockchain network, the second transaction request to execute, viathe blockchain network, a sixth call request to fourth contract addressto transfer a fifth amount of digital assets from the first designatedpublic address to the second designated public address; wherein, inresponse to the sixth call request, the fourth smart contract, executesvia the blockchain network, sixth authorization instructions to verifythe sixth call came from an authorized contract address, and uponverification, to execute a seventh call request to the fifth contractaddress to obtain a sixth amount of digital asset tokens which reflect acurrent balance of digital asset tokens associated with the firstdesignated public address; wherein, in response to the seventh callrequest, the fifth smart contract, executes via the blockchain network,the seventh call request to return the sixth amount of digital assettokens; wherein, in response to the return of the sixth amount ofdigital asset, the fourth smart contract executes, via the blockchainnetwork: (1) a balance verification instruction to confirm that thefifth amount of digital asset tokens is less than or equal to the sixthamount of digital asset tokens, and (2) in the case where the fifthamount of digital asset tokens is less than or equal to the sixth amountof digital asset tokens, execute, via the blockchain network, a seventhcall request to the fifth contract address to set a new balance for thedigital asset tokens in the first designated public address to a seventhamount which equals the sixth amount less the fifth amount; wherein, inresponse to the seventh call, the fifth smart contract executes, via theblockchain network, the seventh call to set and store the new balancefor the first designated public address as the seventh amount andreturns a new balance for the first designated public address as theseventh amount; wherein, in response to the return of the new balance,the fourth smart contract executes, via the blockchain network, aneighth call to add the second amount of digital asset tokens to thebalance associated with the second designated public address; wherein,in response to the eighth call request, the fifth smart contractexecutes, via the blockchain network, the eighth call request to set thebalance of digital asset tokens in the second designated public addressat a seventh amount which includes the addition of the second amount toa previous balance associated with the second designated public address;and wherein the first user device confirms that the balance of digitalasset tokens in the first designated public address is the sixth amountof digital asset tokens based on reference to the blockchain.

In embodiments, the second transaction request includes secondtransaction fee information for miners in the blockchain network toprocess the second transaction request.

In embodiments, the balance of digital asset tokens in the seconddesignated public address is returned to the fourth contract address.

In embodiments, the balance of digital asset tokens in the second publicaddress is returned to the first smart contract address.

In embodiments, a second user device confirms that the balance of thedigital asset tokens in the second designated public address is theseventh amount of digital asset tokens based on reference to theblockchain.

In embodiments, the method further includes the steps of: (k) providinga third designated key pair, comprising a third designated public key ofthe underlying digital asset and a corresponding third designatedprivate key, and wherein the third designated private key is stored on athird computer system which is connected to the distributed publictransaction ledger through the Internet; (l) receiving, by theblockchain network, from the third computer system, via the underlyingblockchain, a second transaction request: (A) from the third designatedpublic key address; (B) to the fifth contract address; and (C) includinga second message comprising a request to burn a fifth amount of digitalasset tokens from a balance associated with the third designated publickey address; wherein the second transaction request is digitally signedby a third designated private key; wherein the fourth smart contractexecutes, via the blockchain network, the second transaction request toexecute, via the blockchain network, a sixth call request to the fifthcontract address to obtain a sixth amount of digital asset tokens whichreflect a current balance of digital asset tokens associated with thethird designated public key address; wherein, in response to the sixthcall request, the fifth smart contract, executes via the blockchainnetwork, the seventh call request to return the sixth amount of digitalasset tokens; wherein, in response to the return of the sixth amount ofdigital asset, the fourth smart contract executes, via the blockchainnetwork: (1) a balance verification instruction to confirm that thefifth amount of digital asset tokens is less than or equal to the sixthamount of digital asset tokens; and (2) in the case where the fifthamount of digital asset tokens is less than or equal to the sixth amountof digital asset tokens, execute, via the blockchain network, a seventhcall request to the fifth contract address to set a new balance for thedigital asset tokens in the third designated public key address to aseventh amount which equals the sixth amount less the fifth amount;wherein, in response to the seventh call, the fifth smart contractexecutes, via the blockchain network, the seventh call to set and storethe new balance for the third designated public key address as theseventh amount and returns the new balance for the third designatedpublic key address as the seventh amount; wherein, in response to thereturn of the new balance, the fourth smart contract executes, via theblockchain network, an eighth call request to the fifth contract addressto obtain a total supply of digital asset tokens in circulation;wherein, in response to the eighth call request, the fifth smartcontract executes, via the blockchain network, the eighth call requestand returns, to the fourth contract address, an eighth amount of digitalasset tokens corresponding to the total supply of digital asset tokensin circulation; wherein, in response to the return of the eighth amount,the fourth smart contract, executes via the blockchain network, a ninthcall request to the fifth contract address to set a new total supply ofdigital asset tokens in circulation to a ninth amount, which is theeighth amount less the fifth amount; and wherein, in response to theninth call request, the fifth smart contract, executes via theblockchain network, the ninth call request and sets a new total supplyof digital asset tokens in circulation at the ninth amount, and returnsto the fourth contract address.

In embodiments, the third designated key pair is the first designatedkey pair.

In embodiments, the third designated key pair is not the seconddesignated key pair.

In embodiments, the third designated key pair is the second designatedkey pair.

In embodiments, the third designated key pair is not the firstdesignated key pair.

In embodiments, the third computer system is the first computer system.

In embodiments, the third computer system is not the first computersystem.

In embodiments, the administrator computer system comprises the firstcomputer system and the third computer system.

In embodiments, the administrator computer system comprises the firstcomputer system and the second computer system.

In embodiments, the second smart contract instructions include sixthauthorization instructions related to modifying a token supply of thedigital asset token.

BRIEF DESCRIPTION OF THE DRAWINGS

Exemplary embodiments of the present invention will be described withreferences to the accompanying figures, wherein:

FIG. 1 is a schematic diagram of a digital asset network in accordancewith exemplary embodiments of the present invention;

FIG. 2 is an exemplary screen shot of an excerpt of an exemplary bitcointransaction log showing digital addresses in accordance with exemplaryembodiments of the present invention;

FIG. 2A is an exemplary screen shot of a Security Token ledger inaccordance with exemplary embodiments of the present invention;

FIG. 3 is an exemplary exchange agent interface in accordance withexemplary embodiments of the present invention;

FIGS. 4A-4B are exemplary schematic diagrams illustrating participantsin a digital asset exchange in accordance with exemplary embodiments ofthe present invention;

FIGS. 5A-5B are schematic diagrams of exemplary exchange computersystems in accordance with exemplary embodiments of the presentinvention;

FIG. 6 is an exemplary flow chart for processes for digital assetexchange account creation and account funding in accordance withexemplary embodiments of the present invention;

FIGS. 7A-7B are an exemplary schematic diagram and a corresponding flowchart of a process for digital asset exchange customer account fiatfunding via an exchange-initiated request in accordance with exemplaryembodiments of the present invention;

FIGS. 7C-7E are an exemplary schematic diagram and a corresponding flowchart of a process for digital asset exchange customer account fiatfunding via a customer-initiated request in accordance with exemplaryembodiments of the present invention;

FIGS. 8A-8B are an exemplary schematic diagram and a corresponding flowchart of a process for digital asset exchange account digital assetwithdrawal in accordance with exemplary embodiments of the presentinvention;

FIG. 9A is an exemplary flow chart of the process for purchasing SVCoinfor fiat on a digital asset exchange in accordance with exemplaryembodiments of the present invention;

FIG. 9B is an exemplary flow chart of the process for redeeming SVCoinfor fiat on a digital asset exchange in accordance with exemplaryembodiments of the present invention;

FIG. 10 is an exemplary flow chart of the process of sending tokens fromAlice to Bob on the Ethereum blockchain in accordance with exemplaryembodiments of the present invention;

FIGS. 11A-1-11A-4 illustrate an exemplary embodiment of a dashboard fiatinterface which allows registered users to deposit and/or withdraw fiatwith the digital asset exchange in accordance with exemplary embodimentsof the present invention;

FIGS. 11B-1-11B-4 illustrate an exemplary dashboard digital assetinterface which allows registered users to deposit and/or withdrawaldigital assets with the digital asset exchange system in accordance withexemplary embodiments of the present invention;

FIGS. 11C-1-11C-2 illustrate an exemplary dashboard SVCoin interfacewhich allows registered users to purchase and/or redeem SVCoins for fiator digital with the digital asset exchange system in accordance withexemplary embodiments of the present invention;

FIG. 11D illustrates an exemplary dashboard Security Token interfacewhich allow Security Token issuers to provide instructions to transferSVCoins to Security Token holders in accordance with exemplaryembodiments of the present invention;

FIG. 12 illustrates an exemplary flow reflecting an exemplary embodimentwhere a Security Token issuer initiates a transfer of SVCoins toSecurity Token holders in accordance with exemplary embodiments of thepresent invention;

FIGS. 13A-13H illustrate exemplary embodiments of a token that utilizessmart contracts in accordance with exemplary embodiments of the presentinvention;

FIGS. 14A-14G illustrate an exemplary process flow chart of a processreflecting an exemplary embodiment of a method of issuing a stable valuedigital asset token in accordance with exemplary embodiments of thepresent invention;

FIGS. 15A-15C illustrate an exemplary dashboard of a user interfacewhich allows registered users of a digital asset exchange to depositand/or withdraw SVCoins (referred to as Gemini Dollars) with the digitalasset exchange system in accordance with exemplary embodiments of thepresent invention;

FIG. 16A is an exemplary flowchart of a process for withdrawing stablevalue digital asset tokens from a digital asset exchange computer systemin accordance with exemplary embodiments in the present invention;

FIG. 16B is an exemplary flowchart of a process for authenticating anaccess request by a user device in accordance with exemplary embodimentsin the present invention;

FIG. 16C is an exemplary flowchart of a process for obtaining a withdrawrequest in accordance with exemplary embodiments in the presentinvention;

FIGS. 16D-16E are exemplary flowcharts of a process for processing awithdraw request in accordance with exemplary embodiments in the presentinvention;

FIG. 17A is an exemplary flowchart of a process for depositing stablevalue digital asset tokens in accordance with exemplary embodiments inthe present invention;

FIG. 17B is an exemplary flowchart of a process for authenticating anaccess request by a user device in accordance with exemplary embodimentsin the present invention;

FIG. 17C is an exemplary flowchart of a process for obtaining a depositrequest in accordance with exemplary embodiments in the presentinvention;

FIGS. 17D-17E are exemplary flowcharts of a process for processing adeposit request in accordance with exemplary embodiments in the presentinvention;

FIG. 18A is a schematic drawing of an exemplary collection of systemsfor increasing the total supply of digital asset tokens on an underlyingblockchain in accordance with exemplary embodiments of the presentinvention;

FIG. 18B is a schematic drawing of an exemplary proxy smart contract inaccordance with exemplary embodiments of the present invention;

FIG. 18C is a schematic drawing of an exemplary print limiter contractin accordance with exemplary embodiments of the present invention;

FIG. 18D is a schematic drawing of an exemplary custodian smart contractin accordance with exemplary embodiments of the present invention;

FIG. 18E is a schematic drawing of a store smart contract in accordancewith exemplary embodiments of the present invention;

FIG. 18F is a schematic drawing of an impl smart contract in accordancewith exemplary embodiments of the present invention;

FIG. 19A is a schematic drawing of an exemplary process for increasingthe ceiling of a print limiter in accordance with exemplary embodimentsof the present invention;

FIG. 19B is a schematic drawing of an exemplary process for increasingthe ceiling of a print limiter in accordance with exemplary embodimentsof the present invention;

FIG. 19C is a schematic drawing of an exemplary process of limiting theprint limiter with respect to a public address in accordance withexemplary embodiments of the present invention;

FIG. 19D is a schematic drawing of an exemplary process of a transferrequest in accordance with exemplary embodiments of the presentinvention;

FIG. 19E is a schematic drawing of an exemplary process of a burnrequest in accordance with exemplary embodiments of the presentinvention;

FIG. 20A is a flowchart of an exemplary process of increasing a supplyof tokens of a digital asset token using off-line keys in accordancewith exemplary embodiments of the present invention;

FIG. 20A-1 is a flowchart of an exemplary process of increasing thetotal supply of tokens of a digital asset token using off-line keys inaccordance with exemplary embodiments of the present invention;

FIG. 20B is another flowchart of an exemplary process of increasing thetotal supply of tokens of a digital asset token in accordance withexemplary embodiments of the present invention;

FIG. 20C is another flowchart of an exemplary process of increasing thetotal supply of tokens of a digital asset token in accordance withexemplary embodiments of the present invention;

FIG. 21A is a flowchart of an exemplary process of increasing the totalsupply of tokens of a digital asset token in accordance with exemplaryembodiments of the present invention;

FIG. 21B is a flowchart of an exemplary process of increasing the totalsupply of tokens of a digital asset token in accordance with exemplaryembodiments of the present invention;

FIGS. 22A-22B are schematic diagrams illustrating participants in adigital asset exchange in accordance with exemplary embodiments of thepresent invention;

FIG. 23 is an exemplary flow chart for a process for converting from, toor between digital assets in accordance with exemplary embodiments ofthe present invention;

FIG. 24 is a schematic drawing of an exemplary network for holdingcollateral in a smart contract on an underlying blockchain in accordancewith exemplary embodiments of the present invention;

FIG. 25A is a schematic drawing of a contract parameters database of asmart contract in accordance with exemplary embodiments of the presentinvention;

FIG. 25B is a schematic drawing of data structures associated with anexemplary security token on an underlying blockchain including smartcontract instruction modules in accordance with exemplary embodiments ofthe present invention;

FIG. 25C is a schematic drawing of data structures associated with anexemplary stable value token (SVCoin Token) including smart contractinstruction modules in accordance with exemplary embodiments of thepresent invention;

FIG. 26A is a flow chart of a processes for holding collateral for asecurity token in the form of a stable value token in a smart contracton an underlying blockchain in accordance with exemplary embodiments ofthe present invention;

FIGS. 26B-26C are flowcharts of an exemplary sub-process of setting up atrade between a first user and a second user in accordance withexemplary embodiments of the present invention;

FIG. 26D is a flowchart of another exemplary sub-process of setting up atrade between a first user and a second user in accordance with anotherexemplary embodiment of the present invention;

FIG. 26E is a flowchart of an exemplary sub-process of collecting excesscollateral from a first user or a second user in a trade in accordancewith exemplary embodiments;

FIG. 26F is a flowchart of another exemplary sub-process of collectingexcess collateral from a first user and a second user in a trade inaccordance with exemplary embodiments;

FIGS. 27A-27B are exemplary graphical user interfaces (GUIs) showingexemplary published contracts in accordance with exemplary embodiments;

FIGS. 27C-27D are exemplary GUIs showing exemplary first indications ofinterest from user Alice in accordance with exemplary embodiments;

FIGS. 27E-27F are exemplary GUIs showing exemplary second indications ofinterest from user Bob in accordance with exemplary embodiments;

FIG. 28 is a flow chart of a processes for generating a smart contracton an underlying blockchain in accordance with exemplary embodiments ofthe present invention;

FIGS. 29A-29D are exemplary block diagrams of components of securitysystems for an ETP holding digital math-based assets in accordance withvarious exemplary embodiments of the present invention;

FIGS. 30A-30D are exemplary block diagrams of components of securitysystems for an exchange holding digital math-based assets in accordancewith various exemplary embodiments of the present invention;

FIGS. 31A-31D are schematic diagrams of cold storage vault systems inaccordance with exemplary embodiments of the present invention;

FIGS. 32A-32B are flow charts of exemplary processes for creating andsecuring digital wallets in accordance with exemplary embodiments of thepresent invention;

FIGS. 33A-33D are flow charts of exemplary processes for generatingdigital asset accounts and securely storing the keys corresponding toeach account in accordance with exemplary embodiments of the presentinvention;

FIG. 34 is a flow chart of an exemplary process for retrieving securelystored keys associated with a digital asset account in accordance withexemplary embodiments of the present invention;

FIG. 35 is a flow chart of a method of performing a secure transactionin accordance with exemplary embodiments of the present invention;

FIGS. 36A-36B are schematic diagrams of vault arrangements for a digitalasset network in accordance with exemplary embodiments of the presentinvention;

FIGS. 37A-37B are flow charts of processes for generating key storageand insurance in accordance with exemplary embodiments of the presentinvention;

FIGS. 38A-38C are flow charts of processes for recovering key segmentsin accordance with exemplary embodiments of the present invention; and

FIGS. 39A-39E are flow charts of processes for increasing a total supplyof digital asset tokens in accordance with exemplary embodiments of thepresent invention.

DETAILED DESCRIPTION

The present invention generally relates to a system, method and programproduct for the generating and distribution of a stable value digitalasset token tied to an underlying blockchain.

Digital Math-Based Assets and Bitcoin

A digital math-based asset is a kind of digital asset based upon acomputer generated mathematical and/or cryptographic protocol that may,among other things, be exchanged for value and/or be used to buy andsell goods or services. A digital math-based asset may be a non-tangibleasset that is not based upon a governmental rule, law, regulation,and/or backing. The Bitcoin system represents one form of digitalmath-based asset. The Ethereum system represents another form of digitalmath-based asset, which allows for smart contracts, as discussed below.

A bitcoin may be a unit of the Bitcoin digital math-based asset. Anether may be a unit of the Ethereum digital math-based asset.

Other examples of digital math-based assets include Bitcoin, Ethereum,Ripple, Cardano, Litecoin, NEO, Stellar, IOTA, NEM, Dash, Monero, Lisk,Qtum, Zcash, Nano, Steem, Bytecoin, Verge, Siacoin, Stratis, BitShares,Dogecoin, Waves, Decred, Ardor, Hshare, Komodo, Electroneum, Ark,DigiByte, E-coin, ZClassic, Byteball Bytes, PIVX, Cryptonex, GXShares,Syscoin, Bitcore, Factom, MonaCoin, ZCoin, SmartCash, Particl, Nxt,ReddCoin, Emercoin, Experience Points, Neblio, Nexus, Blocknet,GameCredits, DigitalNote, Vertcoin, BitcoinDark, Bitcoin Cash, Skycoin,ZenCash, NAV Coin, Achain, HTMLCOIN, Ubiq, BridgeCoin, Peercoin,PACcoin, XTRABYTES, Einsteinium, Asch, Counterparty, BitBay, Viacoin,Rise, Guiden, ION, Metaverse ETP, LBRY Credits, Crown, Electra, Burst,MinexCoin, Aeon, SaluS, DECENT, CloakCoin, Pura, ECC, DeepOnion,Groesticoin, Lykke, Steem Dollars, I/O Coin, Shift, HempCoin, Mooncoin,Dimecoin, Namecoin, Feathercoin, Diamond, Spectrecoin, Filecoin, Tezos,PPCoin, Tonal bitcoin, IxCoin, Devcoin, Freicoin, I0coin, Terracoin,Liquidcoin, BBQcoin, BitBars, Gas, Tether, Ether Classic and PhenixCoin,to name a few. In embodiments, digital math-based assets, such asbitcoin, may be accepted in trade by merchants, other businesses, and/orindividuals in many parts of the world.

Digital assets may also include “tokens,” which like other digitalassets can represent anything from loyalty points to vouchers and IOUsto actual objects in the physical world. Tokens can also be tools, suchas in-game items, for interacting with other smart contracts. A token isa “smart contract” running on top of a blockchain network (such as theEthereum Blockchain, the Bitcoin Blockchain, to name a few). As such, itis a set of code with an associated database. In embodiments, thedatabase may be maintained by an issuer. The code describes the behaviorof the token, and the database is basically a table with rows andcolumns tracking who owns how many tokens.

In embodiments, a smart contract may be a computer protocol intended todigitally facilitate, verify, or enforce the negotiation or performanceof credible transactions without third parties. In embodiments, smartcontracts may also allow for the creation of tokens.

In embodiments, a digital math-based asset may be based on an opensource mathematical and/or cryptographic protocol, which may exist on adigital asset network, such as a Bitcoin network or an Ethereum network.The network may be centralized (e.g., run by one or more centralservers) or decentralized (e.g., run through a peer-to-peer network).Digital math-based assets may be maintained, tracked, and/oradministered by the network.

A digital math-based asset system may use a decentralized electronicledger system, which may be maintained by a plurality of physicallyremote computer systems. Such a ledger may be a public transactionledger, which may track asset ownership and/or transactions in a digitalmath-based asset system. The ledger may be a decentralized publictransaction ledger, which can be distributed to users in the network(e.g., via a peer-to-peer sharing). Ledger updates may be broadcast tothe users across the network. Each user may maintain an electronic copyof all or part of the ledger, as described herein. In embodiments, adigital asset system may employ a ledger that tracks transactions (e.g.,transfers of assets from one address to another) without necessarilyidentifying the assets themselves.

In embodiments, a digital asset ledger, such as the Bitcoin blockchainor the Ethereum blockchain, can be used to achieve consensus and tosolve double-spending problems where users attempt to spend the samedigital assets in more than one transaction. In embodiments, before atransaction may be cleared, the transaction participants may need towait for some period of time, e.g., a six confirmation wait (typicallyone hour in the context of the Bitcoin network, 15 minutes in thecontext of the Litecoin network, to name a few) before feeling confidentthat the transaction is valid (e.g., not a double count). Each update tothe decentralized electronic ledger (e.g., each addition of a block tothe Bitcoin blockchain or the Ethereum blockchain) following executionof a transaction may provide a transaction confirmation. After aplurality of updates to the ledger (e.g., 6 updates) the transaction maybe confirmed with certainty or high certainty.

In embodiments, a blockchain can be a public transaction ledger of thedigital math-based asset that is maintained by a distributed network,such as the Bitcoin network or the Ethereum network. For example, one ormore computer systems (e.g., miners) or pools of computer systems (e.g.,mining pools) can solve algorithmic equations allowing them to addrecords of recent transactions (e.g., blocks), to a chain oftransactions. In embodiments, miners or pools of miners may perform suchservices in exchange for some consideration such as an upfront fee(e.g., a set amount of digital math-based assets) and/or a payment oftransaction fees (e.g., a fixed amount or set percentage of thetransaction) from users whose transactions are recorded in the blockbeing added. In embodiments, digital assets in the form of a digitalasset token, such as Gas, may be used to pay such fees.

The digital asset network (e.g., Bitcoin network or Ethereum Network)may timestamp transactions by including them in blocks that form anongoing chain called a blockchain. In embodiments, the addition of ablock may occur periodically, e.g., approximately every 15 seconds,every minute, every 2.5 minutes or every 10 minutes, to name a few. Suchblocks cannot be changed without redoing the work that was required tocreate each block since the modified block. The longest blockchain mayserve not only as proof of the sequence of events but also records thatthis sequence of events was verified by a majority of the digital assetnetwork's computing power. The blockchain recognized by the nodescorresponding to the majority of computing power, or some otherconsensus mechanism, will become the accepted blockchain for thenetwork. In embodiments, confirmation of a transaction may be attainedwith a high degree of accuracy following the addition of a fixed numberof blocks to the blockchain (e.g., six blocks) after a transaction wasperformed and first recorded on the blockchain. As long as a majority ofcomputing power (or other consensus mechanism) is controlled by nodesthat are not cooperating to attack the network, they will generate thelongest blockchain of records and outpace attackers.

There are a variety of consensus mechanisms (or protocols) that may beused to verify transactions recorded in a blockchain. A few non-limitingexamples of these mechanisms are discussed below, however, otherprotocols may be used in accordance with exemplary embodiments of thepresent invention.

For example, the proof of control protocol is one example of a consensusmechanism and is used, for example, in the Bitcoin blockchain. A moredetailed discussion of proof of control protocols can be found inco-pending U.S. patent application Ser. No. 15/920,042 filed Mar. 13,2018 entitled SYSTEMS, METHODS, AND PROGRAM PRODUCTS FOR VERIFYINGDIGITAL ASSETS HELD IN A CUSTODIAL DIGITAL ASSET WALLET, the entirecontent of which is hereby incorporated by reference herein.

The proof of stake protocol is another optional protocol that may beimplemented by blockchains. In this type of protocol, the validator'sstake is represented by the amount of digital assets held. Validatorsaccept, reject or otherwise validate a block to be added to theblockchain based on the amount of digital assets held by the Validatoron the blockchain. If the Validators are successful in validating andadding the block, such a protocol, in embodiments, will award successfulValidators are a fee in proportion to their stake.

The delegated proof of stake protocol is another protocol that isavailable and is, for example, used by the EOS blockchain. In thisprotocol, blocks are produced in a fixed number in rounds (e.g., 21 forEOS). At the start of every such round, block producers are chosen. Anumber less than all of the producers (e.g., 20 in EOS) areautomatically chosen while a corresponding number are chosenproportional to the number of their votes relative to other producers.In embodiments, the remaining producers may be shuffled using apseudorandom number derived from the block time, for example. Inembodiments, other forms of randomized selection may be used. To ensurethat regular block production is maintained, in embodiments, block timeis kept short (e.g., 3 seconds for EOS) and producers may be punishedfor not participating by being removed from consideration. Inembodiments, a producer has to produce a minimal number of block, e.g.,at least one block every 24 hours to be in consideration. All of thenodes will, by default, not switch to a fork which does not include anyblocks not finalized by a sufficient majority (e.g., 15 of the 21producers) regardless of chain length. Thus, in EOS, each block mustgain 15 of 21 votes for approval to be considered a part of the chain.

In embodiments, a delegated byzantine fault tolerance protocol may beused as a consensus mechanism. For example, NEO uses this type ofprotocol. In this protocol, one of the bookkeeping nodes is randomlychosen as a “speaker.” The speaker then looks at all the demands of the“citizens,” (e.g., all of the holders of the digital asset), and createsa “law” (e.g., a rule governing the protocol). The speaker thencalculates a “happiness factor” of these laws to see if the number isenough to satisfy the citizen's needs or not. The speaker then passesthe happiness factor down to the delegates (e.g., the other bookkeepingnodes). The delegates may then individually check the speaker'scalculations. If the speaker's number matches the delegate's number,then the delegates give their approval, and if not, then they give theirdisapproval. In embodiments, a sufficient majority (e.g., 66% in NEO) ofthe delegates need to give their approval for the law to pass, i.e. forthe block to be added. If a sufficient majority is not obtained (e.g.,less than 66% approval), then a new speaker is chosen and the processstarts again.

Ripple uses an algorithm in which each server gathers all validtransactions that have not yet been applied and makes them public. Eachserver then amalgamates these transactions and votes on the veracity ofeach. Transactions that receive at least a minimum number of yes voteswill move into another round of voting. A minimum of 80% approval isrequired before a transaction is applied.

These and other protocols may be used to generate a blockchain inaccordance with exemplary embodiments of the present invention.

In embodiments, transaction messages can be broadcast on a best effortbasis, and nodes can leave and rejoin the network at will. Uponreconnection, a node can download and verify new blocks from other nodesto complete its local copy of the blockchain.

In the exemplary Bitcoin system, a bitcoin is defined by a chain ofdigitally signed transactions that began with its creation as a blockreward through bitcoin mining. Each owner transfers bitcoin to the nextowner by digitally signing them over to the next owner in a bitcointransaction which is published to and added on to a block on theblockchain. A payee can then verify each previous transaction, e.g., byanalyzing the blockchain to verify the chain of ownership.

Other examples of different types of blockchains noted above that areconsistent with embodiments of present invention pose unique problems.Certain currencies present unique challenges in that transactions and/orwallets or digital asset addresses associated therewith may be shielded(e.g., not viewable by the public on the ledger). For example, Monero isbased on the CryptoNight proof-of-work hash algorithm and possessessignificant algorithmic differences relating to blockchain obfuscation.Monero provides a high level of privacy and is fungible such that everyunit of the currency can be substituted by another unit. Monero istherefore different from public-ledger cryptocurrencies such as Bitcoin,where addresses with coins previously associated with undesired activitycan be blacklisted and have their coins refused by others.

In embodiments, “proof of brain” may be a type of token reward algorithmused in social media blockchain systems that encourages people to createand curate content. In embodiments, proof of brain may enable tokendistribution by upvote and like-based algorithms, which may beintegrated with web sites to align incentives between application ownersand community members to spur growth.

In particular, in Monero, ring signatures mix spender's address with agroup of others, making it more difficult to establish a link betweeneach subsequent transaction. In addition, Monero provides “stealthaddresses” generated for each transaction which make it difficult, ifnot impossible, to discover the actual destination address of atransaction by anyone else other than the sender and the receiver.Further, the “ring confidential transactions” protocol may hide thetransferred amount as well. Monero is designed to be resistant toapplication-specific integrated circuit mining, which is commonly usedto mine other cryptocurrencies such as Bitcoin. However, it can be minedsomewhat efficiently on consumer grade hardware such as x86, x86-64, ARMand GPUs, to name a few.

Another example of a modified blockchain consistent with exemplaryembodiments of the present invention discussed above is Darkcoin.Darkcoin adds an extra layer of privacy by automatically combining anytransaction its users make with those of two other users—a feature itcalls Darksend—so that it will be more difficult to analyze theblockchain to determine where a particular user's money ended up.

Yet another example of a modified blockchain consistent with exemplaryembodiments of the present invention discussed above is Zcash. The Zcashnetwork supports different types of transactions including:“transparent” transactions and “shielded” transactions. Transparenttransactions use a transparent address (e.g., “t-address”). Inembodiments, transactions between two t-addresses behave like Bitcointransactions and the balance and amounts transferred are publiclyvisible on the Zcash blockchain. Unlike the Bitcoin Blockchain, theZcash network may also support shielded transactions using a shieldaddress (e.g., “z-address”). In embodiments, the “z-address” providesprivacy via zero-knowledge succinct noninteractive arguments ofknowledge (e.g., “zk-SNARKS” or “zero-knowledge proofs”). The balance ofa z-address is not publicly visible on the Zcash blockchain—the amounttransferred into and out of a z-address is private if between twoz-addresses—but may be public if between a z-address and a t-address.

In embodiments, a digital asset based on a blockchain, may, in turn,include special programming, often referred to as “smart contracts”,which allow for the creation of “tokens”, which in turn are digitalassets based on digital assets. In embodiments, tokens may be ERC-20tokens, and used in conjunction with ERC-20 token standard as aprogramming language. In embodiments, other protocols may be usedincluding but not limited to ERC-223 and ERC-721, to name a few. Inembodiments, smart contracts may be written on other smart contracts toprovide for increased functionality. One non-limiting example of thistype of structure is the open source Cryptokitties game in which digitalkittens are provided as ERC-721 tokens with a series of smart contractsprovided to define how the kittens will interact with each other andwith users. In embodiments, programming modules may be added to and/ortransferred with programming modules associated with specific tokens. Byway of illustration, a first token, e.g., a Cryptokitten Tiger, maypurchase a second token, e.g., a digital “hat,” that will then becomeassociated with the first token to be a Tiger with a hat, and remainwith the first token when transferred. Thus, by way of illustration, inthe context of example embodiments of the present invention, the firsttoken could be, e.g., a security token, and the second token could be,e.g., an account holding SVCoins, or a right to request SVCoins fromanother account as discussed below. If the first token is transferred,the second token would transfer with the ownership of the first token.

For example, digital assets can include tokens, which like other digitalassets that can represent anything from loyalty points to vouchers andIOUs to actual objects in the physical world. Tokens can also be tools,such as in-game items, for interacting with other smart contracts. Atoken is a smart contract running on top of a blockchain network (suchas the Ethereum Blockchain, the Bitcoin Blockchain, to name a few). Assuch, it is a set of code with an associated database. In embodiments,the database may be maintained by an issuer. In embodiments, thedatabase may be included as part of the blockchain. In embodiments, theledger may be maintained in the first instance as a database in asidechain by the issuer or agent of the issuer and subsequentlypublished and stored as part of a blockchain. The code describes thebehavior of the token, and the database may be a table with rows andcolumns tracking who owns how many tokens.

If a user or another smart contract within the blockchain network (suchas the Ethereum Network) sends a message to that token's contract in theform of a “transaction,” the code updates its database.

So, for instance, as illustrated in FIG. 10, using a token based on theEthereum Network for illustration purposes, when a wallet app sends amessage to a token's contract address to transfer funds from Alice toBob, the following process occurs.

In embodiments, an underlying blockchain, like the Bitcoin Block chain,may have limited or no smart contract capabilities.

In such embodiments, an overlying protocol, such as Omni Layer(https://www.omnilayer.org/) may also be used to create custom digitalassets on such an underlying blockchain, like the Bitcoin blockchain, asdescribed in https://github.com/OmniLayer/spec. In embodiments, a smartcontract may be used for transactions involving Bitcoin through the useof a two way peg with side chain. The side chain can share miners withthe Bitcoin blockchain and allows smart contracts to be run, such ascontracts using the Ethereum virtual machine. When Bitcoin is to be usedin the smart contract side chain, the Bitcoin is locked and an equalamount of side chain currency, an example of which is Super Bitcoin(SBTC), is assigned to the corresponding address. After the smartcontract transaction is completed, the side chain currency is locked andthe Bitcoin is unlocked. An example of such a side chain is Rootstock.

In embodiments, where the blockchain is the Bitcoin blockchain, andanother protocol is used as a layer over the Bitcoin blockchain toprovide for smart contract functionality. For example, the otherprotocol may be a two-way peg of stable value digital asset tokens tobitcoin and a sidechain that shares miners with the Bitcoin blockchain.In embodiments, the other protocol is an omni layer protocol.

For illustration purposes, FIG. 10 shall be described with respect to atoken on a block chain with ERC20 smart chain capabilities, such as theEthereum Block chain and the NEO Block chain, to name a few.

In step S1001, at the token issuer computer system, a token, such as aStable Value Token by way of illustration, is created. In embodiments,the token can be other forms of tokens, such as a Security Token, orother form of tokens. In embodiments, each token may have a “ERC20Contract Wallet Address” (“Contract Address”) which is an address on theblockchain at which the code for the smart contract is stored. Inembodiments, the smart contract may include instructions to perform atleast: (1) token creation, (2) token transfer, (3) token destruction;and (4) updating smart contract coding, to name a few. In addition, thesmart contract may include additional instructions related to authorityto conduct operations and/or transactions associated with the smartcontract or token.

In embodiments, of the present invention, the minimal specification fora Token, such as a Stable Value Token, may include instructions toperform at least: (1) a “total Supply” function, which when called, willrespond with a count of the number of tokens in existence; (2) a“balanceOf” function, which when called with a specific account(address) as a parameter, responds with the count of the number oftokens owned by that account; and (3) a “transfer” function, which is anexample of a state modifying function, that, when called, given one ormore target accounts and corresponding transferred amounts asparameters, the transfer function will decrease the balance of thecaller account by the corresponding transfer amounts, and increase thetarget accounts by the target amounts (or fail if the caller account hasinsufficient amounts or if there are other errors in the parameters).

In embodiments, a Stable Value Token may be created with a fixed supplyof tokens at the time of its creation. For example, a Stable Value Tokenmay be created with a supply of 21 million tokens and set Address 1(mathematically associated with a private key 1) as the owner of all 21million tokens. Thereafter, private key 1 will be required to generate acall to the transfer function in order to assign some portion of the 21million tokens with a second address 2 (mathematically associated with aprivate key 2) or any other address (also mathematically associated witha corresponding private key).

In embodiments, a Stable Value Token may be created with a variablesupply of tokens which can be set to increase or decrease after originalcreation. In such embodiments, the minimum functions required will alsoinclude: (4) a “print” function, which is another example of a statemodifying function, that when called allows for the creation ofadditional Stable Value Tokens into the total Supply of Stable ValueTokens; and (5) a “burn” function, which is also another example of astate modifying function, that when called allows for the destruction ofpreviously created Stable Value Token from the total Supply of theStable Value Tokens. As discussed below in greater detail, inembodiments, the print and burn function may include limits on theAddresses that are allowed to call those functions.

Currently, due to the immutable nature of the Ethereum blockchain, oncea smart contract is written to a specific Contract Address it cannot bechanged. However, in embodiments, the various functions called for inthe Contract Address may be associated with specific authorized keypairs of public keys (or “addresses”) and corresponding private keys(which are mathematically associated with public keys). In embodiments,one or more private keys may be stored off-line in, what is sometimesreferred to as, a designated cold storage wallet associated with thetoken issuer. In such embodiments, keys may be generated, stored, andmanaged on board hardware security modules (HSMs). For example, HSMs,e.g., each a “signer,” should have achieved a rating of FIPS PUB 140-2Level 3 (or higher) In embodiments, one or more private keys may bestored on-line in, what is sometimes referred to as a designated hotstorage wallet associated with the token issuer. In embodiments, theContract Address may include instructions which are associated withauthorizing one or more designated key pairs stored off-line in, e g.,one or more cold storage wallets on one or more air-gapped computersystems associated with the token issuer, but may also give at leastsome permission to perform operations by one or more designated keypairs stored on-line, in, e.g., one or more hot wallets associated withthe token issuer and/or a token administrator on behalf of the tokenissuer on one or more computer systems connected to the digital assetcomputer system. In embodiments, the on-line computer systems would beco-located with the digital asset computer systems. In embodiments, theStable Value Tokens may be created in batches (for example, 100,000SVCoins worth $100,000 U.S. dollars) by a designated key pair (such asan off-line designated key pair) authorized by smart contract andassigned by such a key pair to a designated address associated with onon-line public key for transactions as necessary.

In embodiments, a Stable Value Token database is maintained in ablockchain, such as the Ethereum blockchain, for example. Inembodiments, the ledger may be maintained, in the first instance, as adatabase in a sidechain by the issuer or agent and subsequentlypublished and stored as part of a blockchain.

In embodiments, a Stable Value Token database is maintained in ablockchain, such as the Ethereum blockchain, for example. Inembodiments, the ledger may be maintained in the first instance as adatabase in a sidechain by the issuer or agent and subsequentlypublished and stored as part of a blockchain.

In embodiments, Stable Value Tokens may be generated on the fly,however, in this case, the contract code, which is the executable codethat is stored at the Contract Address location on the blockchain, maydesignate one or more public addresses corresponding to one or moreon-line private keys held in, e.g., a hot wallet(s), or one or morepublic addresses corresponding on one or more off-line public keys heldin, e.g., a cold wallet(s), or some combination thereof, as theauthorized caller of some functionality. A more detailed discussion ofexemplary structures for hot wallets and cold wallets is presented inU.S. Pat. No. 9,892,460 issued Feb. 13, 2018 entitled SYSTEMS, METHODS,AND PROGRAM PRODUCTS FOR OPERATING EXCHANGE TRADED PRODUCTS HOLDINGDIGITAL MATH-BASED ASSETS, the entire content of which is incorporatedby herein by reference. In embodiments, Contract Wallets may bemaintained by the token issuer and which would hold the private keyassociated with the token on an associated device. In embodiments,Contract Wallets may be provided on a user computer device and hold theprivate key associated with the token. In such embodiments, a usercomputer device may include a software application to provide secureaccess to the token issuer such that the user can engage intransactions.

In embodiments, a subset of two or more corresponding key pairs from alarger collection of key pairs may be required to engage in certaintransaction. For example, 2 of 3, 2 of 5, or 3 of 5, keys may berequired to engage in certain transactions. In embodiments, suchtransactions may include sensitive or relatively high risk transactions.

In embodiments, the smart contract(s) and associated authorized privatekeys may be maintained by the SVCoin issuer and which would hold theauthorized private key(s) associated with the token on an associateddevice.

By way of illustration, an ERC-20 Contract can include the followingrepresentative type of functions as shown in Table 1 in its programmingof a Smart Contract associated with a particular token, such as asecurity token or a stable value token:

TABLE 1 1 // 2 // ERC Token Standard #20 Interface 3 //https://github.com/ethereum/EIPs/blob/master/EIPS/eip-20-token-standard.md4 //----------------------------------------------------------------------------5 contract ERC20Interface { 6  function total Supply( ) public constantreturns (uint); 7  function balanceOf(address tokenOwner) publicconstant returns (uint balance); 8  function allowance(addresstokenOwner, address spender) public constant returns (uint remaining); 9 function transfer(address to, uint tokens) public returns (boolsuccess); 10  function approve(address spender, uint tokens) publicreturns (bool success); 11  function transferFrom(address from, addressto, uint tokens) public returns (bool success); 12 13  eventTransfer(address indexed from, address indexed to, uint tokens); 14 event Approval(address indexed tokenOwner, address indexed spender,uint tokens);

Some of the tokens may include further information describing the tokencontract such as shown Table 2:

TABLE 2 1  string public constant name = ″Token Name″; 2  string publicconstant symbol = ″SYM″; 3  uint8 public constant decimals = 18; // 18is the most common number of decimal places

In embodiments, a more elaborate smart contract can be set up to allowtoken issuers to have hybrid control over which key pairs have authorityto affect the token supply and distribution. In embodiments, a hybridcombination of on-line and off-line key pairs can be used to control thesupply and distribution of tokens.

For example, in embodiments, a smart contract may include astate-changing function such as limitedPrint, where the authorizedcaller of such function would be authorized only to print (or issue) aspecific limited amount of tokens. In embodiments, the limitedPrintfunction may authorize printing or issuing of tokens for a set period oftime. In embodiments, the limitedPrint function may authorize printingor issuing of only a certain number of tokens over a set period of time.In embodiments, the limitedPrint function may be used with an on-linekey pair (e.g., hot wallet), to allow for fast and efficient tokencreation, but limit risk of unauthorized takeover of the on-line keypair to the set limit.

In conjunction with a limitedPrint command, a separate state-changingfunction of raiseCeiling can be used to increase the authority for theon-line key pair using a different key pair, such as an off-line keypair (e.g., cold wallet), which is considered to be more secure.

In embodiments, using a limitedPrint function with a set limit that canbe implemented by one or more designated on-line key pairs (e.g., hotwallets), and a raiseCeiling function which may change that limit underthe authority of a different set of one or more designated off-line keypairs (e.g., cold wallets), the automated increases in the token supplythrough on-line control will only continue up until the ceiling isreached, at which point further intervention through off-line control isrequired. In embodiments, a subset of two or more corresponding keypairs from a larger collection of key pairs may be required to engage incertain transaction. For example, 2 of 3, 2 of 5, or 3 of 5, to name afew, keys may be required to engage in certain transactions. Inembodiments, as noted above, such transactions may include sensitive orrelatively high-risk transactions.

One should consider the difference between the current token supply andthe supply ceiling as part of the tokens at risk. If the current tokensupply has decreased through the use of burn, then the effective fundsat risk could have increased without a corresponding decrease in thesupply ceiling. The ceiling can be lowered by on-line control, through afunction called lowerCeiling. This allows for relinquishing some portionof what has been granted through off-line control to limit the effectivefunds at risk through compromise of on-line key management systems. Inembodiments, a limit on number of tokens that can be burned may also beincluded.

In embodiments, as illustrated in FIG. 13A, the token may be set upusing at least three core smart contracts, e.g., ERC20Proxy 1310,ERC20Impl 1320, and ERC20Store 1330 that cooperatively implement anERC20 compliant token.

In the context of a ERC20 compliant token on the Ethereum blockchain,there is one, and will only ever be one instance of ERC20Proxy 1310.This is the smart contract that users of the token treat as the tokencontract. Thus, ERC20Proxy 1310 can be considered the permanent face ofinteracting with the token on the Ethereum blockchain.

However, in embodiments, ERC20Proxy 1310 may have almost no code anddoes not keep any state information itself. Instead, in embodiments,ERC20Proxy 1310 has one or more implementations (e.g., ERC20 Impl 1320,ERC20 Impl (1) 1340, ERC20 Impl (2), to name a few) that executes thelogic of the token. S1312 “impl” represents a delegation from ERC20Proxy 1310 to ERC20Impl 1320. Thus, the instance of ERC20Impl 1320executes the specific delegated functions. ERC20Impl 1320 may furtherlimit the authority to implement to the specific delegated functions toonly specified trusted callers (e.g., as shown in FIGS. 13C, 13G and13H, one or more off-line key set 1362, one or more on-line key set1364, to name a few). S1314 proxy illustrates the authorization ofERC20Impl 1320 executing logic on behalf of ERC20Proxy 1310, throughcall functions from one or more authorized addresses.

In embodiments, state information, such as token balances, may bemaintained in a separate instance, e.g., ERC20Store 1330, a “backingstore.” In such embodiments, ERC20Store 1330 would own the delegatedstate of the token. S1322 “store” illustrates the delegation of stateinformation from ERC20Impl 1320 to ERC20Store 1330. In embodiments, theinstance of ERC20Store 1330 may execute updates to the state of thetoken, such as updates to token balances that occur during a tokentransfer to one or more designated key sets. S1324 “impl” represents theaddress that the ERC20Store 1330 will permit to invoke the updatefunctions. In embodiments, that address is the “Contract Address” of theactive version of ERC20Impl 1320.

This separation of duties—public face, logic, and storage, forERC20Proxy 1310, ERC20Impl 1320, and ERC20Store 1330,respectively—provides the ability for token issuer to replace the logicof the system at a later date. In embodiments, the logic may be replacedby changing the impl arrows (e.g., S1312 “impl” and S1324 “impl”).

FIG. 13B illustrates an embodiment where a token has been upgraded, bycreating a new instance of ERC20Impl (ERC20Impl (2) 1320A) with a secondversion of the code previously implemented through ERC20Impl 1320. Theinstance of ERC20Proxy 1310 now delegates its implementation in S1312A“impl” to ERC20Impl (2) 1320A (version 2 of the code) instead of theprevious ERC20Impl 1320 (version 1), and the instance of ERC20Store 1330will now only accept calls from ERC20Impl 1320A (version 2). Theoriginal ERC20Impl 1320 (version 1) remains, but has become inert as itis unlinked from the system.

Turning to FIGS. 13C-13F, custodianship will be discussed.

In embodiments, a fourth type of contract, Custodian 1350, may also beimplemented. A Custodian 1350 is logic which designates which key pair(e.g., an Off-Line Keyset 1362), is authorized to control othercontracts in the system (e.g., ERC20Proxy 1310). Contracts cooperatewith Custodian 1350 by awaiting an approval from Custodian 1350 beforeexecuting certain actions. In turn, such approval will require a messagefrom an authorized key pair (e.g., Off-Line Keyset 1362) authorizing theaction (e.g., print tokens, limit tokens, transfer tokens, to name afew).

In embodiments, Custodian 1350 may include a range of control coding. Inembodiments, control coding may include the requirement that at leasttwo designated keysets authorize a specific action (e.g., print token).In embodiments, at the least two keysets may be a subset of a largergroup of keysets (e.g., two of three designated keysets, or two of sixdesignated keysets, or three of five designated keysets, to name a few).In embodiments, when a higher degree of security is desired, the keysetsmay be maintained off-line. In embodiments, when a higher degree ofautomation or speed to access is required, the keysets may be maintainedon-line, such as in a co-located, but separate computer system that isoperatively connected to a customer facing digital asset system.

In embodiments, Custodian 1350 may also exercise control over varioussecurity operations of ERC20Proxy 1310 (e.g., time locking andrevocation, to name a few).

In embodiments, Custodian 1350 may have custodianship of the proxy whichgrants exclusive power to replace the implementation for ERC20Proxy 1310from its current implementation (e.g., ERC20Impl 1320 (version 1)) to anew implementation (e.g., ERC20Impl 1320A (version 2)), as illustratedin FIG. 13B, discussed above. As discussed, in embodiments, onlyauthorized and designated key sets (e.g., off-line key set 1362) willhave the authority in step S1354 signers to authorize the Custodian 1350to modify an implementation of ERC20Proxy 1310.

In embodiments, Custodian contracts with their own respective authorizeddesignated keysets can be set up for other contracts, such as ERC20Store1330 as also shown in FIG. 13C. Thus, by way of example, ERC20Store 1330may designate in S1332 Custodian 1350A as a custodian for certainoperations of ERC20Store. Those operations will only be executed byERC20Store 1330 when designated keyset (such as Off-Line keyset 1362A)sends a message through the blockchain to Custodian 1350A authorizingthe Custodian 1350A to authorize the ERC20Store 1330 to perform thedesignated function. In embodiments, the off-line keyset 1362A may bethe same as, overlap with, or be different from the Off-Line Key Set1362A which may authorize Custodian 1350 with respect to ERC20Proxy1310.

In embodiments, custodianship of the proxy and store also grantsexclusive power to pass custodianship to a new instance of Custodian.Thus, one of the technical computer problems associated with theimmutability of ERC20 smart contracts on the Ethereum blockchain hasbeen solved, thus allowing for a self-upgrade of custodianship. Inembodiments, since a set of signers for a given instance of a Custodianis fixed, a change to the off-line keyset may be implemented insteadhaving a current Custodian authorize itself to be replaced by a newinstance of Custodian with a new set of signers.

Referring now to FIGS. 13D-13F, an exemplary process of upgrading activeimplementation of the pointer relationship of ERCProxy 1310 fromERC20Impl 1320 (version 1) to ERC20Impl 1320A (version 2) will now bediscussed.

FIG. 13D reflects the initial state in which ERC20Proxy 1310 hasCustodian 1350 and in S1312A implemented ERC20 Impl 1320 (version 1) toact as a proxy in S1314A for certain functions of ERC20Proxy 1310.

To swap out the current ERC20Imp11320 (version 1) with an updatedERC20Impl 1320 (version 2), as shown in FIG. 13E, the coding for ERC20Impl 1320 (version 2) needs to be deployed on the blockchain and set itsproxy point (S1314B proxy) to the same ERC20Proxy 1310.

Next, the implementation pointer from ERC20Proxy 1310 which is currentlyset at S1312 (impl) to point to ERC20Impl 1320 (Version 1), needs to bereset to be S1312B “impl” to point to ERC20Impl 1320A (version 2)instead. This change requires the authorization of Custodian 1350, whichin turn requires two signatures from keys in its designated keyset(e.g., Off-Line Keyset 1362) sent to it on the blockchain.

Table 3 represents an exemplary embodiment of the steps used toimplement this process:

TABLE 3 1. lockID = proxy.requestImplChange(imp_2) 2. request=custodian.requestUnlock(lockId,proxy.confirmImpl.Change) 3. Off-linesigning of request 4. custodian.completeUnlock (request, signature_1,signature 2)     a. proxy.confirmImplChange(lockID)

Referring to Table 3, in step 1, a request must be made to ERC20Proxy tochange its instance of ERC20Impl. This request may come from anyaddress, and when the request is made, the function returns a uniquelockId that anyone can use to look up that request.

Next, in step 2, to confirm the pending request, the Custodian contract1350 for ERC20 Proxy 1310 calls requestUnlock and passes as argumentsthe lockId generated for the change request, and the function inERC20Proxy 1310 the Custodian 1350 needs to call to confirm the changerequest. This generates a request, which is a unique identifier for thisunlock request.

In step 3, to complete the unlocking of Custodian and thereforepropagate the change to ERC20Proxy 1310, the digital asset systemoperated by the token issuer uses its off-line key storageinfrastructure to sign the request with the previously approveddesignated key sets. In this example, two signatures are required(signature 1 and signature 2), but other combinations of signatures maybe used consistent with embodiments of the present invention.

In step 4, those signatures are passed into the Custodian'scompleteUnlock function along with the initial request. Once the requestis validated against the signatures, completeUnlock parses the contentof the request and issues the command. In this case, it callsERC20Proxy's confirmImplChange using the lockId generated in the initialERC20Impl change request.

As shown in FIG. 13F, ERC20Proxy 1310 now points with S1312B to theupdated ERC20Impl 1320A (version 2) contract, thus delegating all futurecalls from ERC20Proxy 1310 to the updated contract ERC20 Impl (version2) 1320A. This process can be repeated in the future to upgrade theERC20 Impl (version 2) 1320A to new versions as authorized by theCustodian 1350.

In embodiments, a similar process may also be used to upgrade the activeCustodian 1350. Instead of the pair of functions requestImplChange andconfirmImplChange, the pair of functions requestCustodianChange andconfirmCustodianChange are used instead.

Referring to FIGS. 13G and 13H, a PrinterLimiter 1360 contract may alsobe used as an upgradeable limit on the token supply available.

In the context of FIG. 13G, ERC20Impl 1320 allows printing an unboundedamount of tokens to any arbitrary address. This printing can only bedone by PrintLimiter 1360 contract, which serves as ERC20Impl'scustodian. However, PrintLimiter 1360 can only call this unboundedprinting if it receives a call from its custodian, a separate contractnamed Custodian 1350, which is in turned controlled by signatures fromdesignated keysets (e.g., Off-Line Key Set 1362).

Thus, to print an unbounded amount of tokens, signatures from keys inOff-Line Key Set 1362 need to be sent through the blockchain, toCustodian 1350, which, in turn, then calls through the blockchain,PrintLimiter 1360, which then, in turn, calls through the blockchainERC20Impl 1320 to confirm the print request.

Referring to FIG. 13H, a limited printing option may also beimplemented. Thus, In embodiments, consistent with FIG. 13H, ERC20Impl1320 allows either printing an unbounded amount (which originates fromOff-Line Key Set 1362 as described earlier), or a limited amount whichdoes not require the Off-Line Key Set 1362 to enact. Within PrintLimiter1360 is a “total supply ceiling” variable: a maximum total supply oftokens that any “limited print” operation cannot exceed. This value isset by Off-Line Key Set 1362. PrintLimiter 1360 allows printing newtokens while remaining under that ceiling from a special hot walletaddress. That hot wallet address can call PrintLimiter 1360 directly,which then calls ERC20Impl 1320 to confirm the “limited” printoperation. In embodiments, limits may also be expressed in units oftokens to be issued, time periods or units of tokens per unit of time.In embodiments, for higher risk activities, a time delay may beimplemented even where the activity is authorized. For example, where alarge number of tokens are to be printed, a time delay of, e.g. 15minutes, may be implemented even after authorization is confirmed.

The total supply ceiling can only be raised by Off-Line Key Set 1362. Inembodiments, it can be lowered, however, by On-Line Key Set 1364 orOff-Line Key Set 1362.

Table 4 illustrates exemplary embodiments of code used in smartcontracts on the Ethereum blockchain which implement a cooperativerelationship with an external account or contract that exertscustodianship over the contract following the pattern.

A contract following this type of pattern is capable of carrying outsome action—a portion of the desired operations; however, rather thanexecuting the action directly, the action is first requested, with aunique ‘lock identifier’ returned as the result of the request. Thepending action is stored in the contract state, storing the datanecessary to execute the action in the future, and with the lockidentifier as the lookup key to retrieve the pending action. If thecontract is called by its custodian, receiving a lock identifier as anargument, then the associated pending action, if any, is retrieved andexecuted.

In embodiments, as illustrated in Table 4, the contracts may includemultiple inheritances, so for the purposes of code reuse, a function forgenerating unique lock identifiers is implemented in the contractLockRequestable.

TABLE 4 contract LockRequestable {  uint256 public lockRequestCount; function LockRequestable( ) public {   lockRequestCount = 0;  } function generateLockId( ) internal returns (bytes32 lockId) {   returnkeccak256(block.blockhash(block.number - 1), address(this),++lockRequestCount);  } }

In embodiments, the function generateLockId returns a 32-byte value tobe used as a lock identifier, which is a hash of the following threecomponents: (1) The blockhash of the Ethereum block prior to the blockthat included the Ethereum transaction that executed this function; (2)The deployed address of the instance of the contract that inherits fromLockRequestable; and (3) The current value of the count of allinvocations of generateLockId (within ‘this’ contract).

Component three plays the role of a nonce (in cryptography, a nonce isan arbitrary number that can be used just once) ensuring that a uniquelock identifier is generating no matter how many invocations ofgenerateLockId there are within a single Ethereum transaction or asingle Ethereum block.

Component two ensures that the lock identifier is unique among the setof cooperating contracts that use this identifier generation scheme. Anoncooperative contract authored by a third party may choose to generateidentifiers that overlap, but that is expected not to impact operation.

Finally, component one uses the relative previous blockhash to makefuture lock identifiers unpredictable.

Table 5 illustrates embodiments of code which uses LockRequestable in atemplate consistent with embodiments of the present invention.

TABLE 5 contract C is ..., LockRequestable {  struct PendingAction {   tv;   ...  address public custodian;  mapping (bytes32 => PendingAction)public pendingActionMap;  function C(address _custodian, ...) public {  custodian = _custodian;   ...  }  modifier onlyCustodian {  require(msg.sender == custodian);   _;  }  function requestAction(t_v,...) public returns (bytes32 lockId) {   require(_v != 0);   lockId =generateLockId( );   pendingActionMap[lockId] = PendingAction({    v:_v,    ...   });   emit ActionLocked(lockId, _v, ...);  }  functionconfirmAction(bytes32 _lockId) public onlyCustodian {   PendingActionstorage pendingAction = pendingActionMap[_lockId];   t v =pendingAction.v;   require(v != 0);   ... // copy any other data frompendingAction   delete pendingActionMap[_lockId];   ... // execute theaction   emit ActionConfirmed(_lockId, v, ...);  }  eventActionLocked(bytes32 lockId, t _v, ...);  event ActionConfirmed(bytes32lockId, t _v, ...); }

The function requestAction generates a fresh lock identifier andcaptures the request parameters as a pending action, storing it in amapping associated with the lock identifier.

The function confirmAction is callable only by the designated custodian.The given lock identifier is used to retrieve the associated pendingaction from the contract storage, if it exists, otherwise the functionreverts. The pending action is deleted from storage, which ensures thatthe action will be executed at most once. Finally, the logic of theaction is executed.

In embodiments, there are two requirements to the confirmAction callbackfunction: (1) The function does not have a return value; and (2) Thefunction must only revert if there is no pending action associated withthe lock identifier.

In these embodiments, the custodian receives a failure signal only whenit called with an invalid lock identifier. Any failure cases that mayoccur in the execution of the action logic must be signaled by meansother than return values or reversions (including abortive statementssuch as throw).

Programming consistent with Tables 4 and 5 may be used to implement awide variety of functions in the context of a token including, by way ofexample:

-   Contracts that inherit from the ERC20ImplUpgradeable contract (e.g.,    ERC20Proxy and ERC20Store) control updates to the address that    references an instance of the ERC20Impl contract;-   The ERC20Impl contract to control increases to the token supply;-   The ERC20Holder contract to control ‘withdrawal’ transfers out of    its balance;-   The PrintLimiter contract to control increases to its token supply    ceiling state; and-   Contracts that inherit from the CustodianUpgradeable contract (e.g.,    ERC20Proxy, ERC20Impl, and ERC20Store) to control the passing of    custodianship itself from the current custodian to a new custodian,    to name a few.

In embodiments, other limits or controls may also be built into thesmart contract functionality of the token. For example, in embodiments,it may be necessary for the token issuer to adjust the token ledger toaccount for regulatory activity. For example, there may be a courtordered seizure of funds, or a security issue that may require reversingtransactions during a compromised period, to name a few.

In embodiments, as discussed below, an exchange system may include fraudmanagement computer system 5160. In embodiments, the administratorsystem and/or stable value token issuer system may include, or beoperably connected to, fraud management computer system 5160 or acomparable fraud management computer system. In embodiments, the fraudmanagement computer system may be operated by the exchange, theadministrator, the stable value token issuer or a third party, to name afew.

In embodiments, the fraud management computer system may monitor theblockchain to identify public addresses to and/or from which StableValue Tokens may be transferred. In embodiments, the fraud managementcomputer system may compare the identified public addresses to one ormore lists of suspicious public addresses. In embodiments, where one ofthe identified public addresses corresponds to a suspicious publicaddress, a report may be issued to reflect possible suspicious activity.In embodiments, the report may be provided to the exchange,administrator or stable value token issuer and/or regulatory or lawenforcement authorities. In embodiments, the exchange system,administrator system and/or stable value token issuer system may block atransaction to and/or from a suspicious public address. In embodiments,the exchange system, administrator system and/or stable value tokenissuer system may freeze any Stable Value Tokens associated with thesuspicious public address. In embodiments, the exchange system,administrator system and/or stable value token issuer system may reversea transfer of Stable Value Tokens to and/or from the suspicious address.

In embodiments, the fraud management computer system may be operablyconnected to ledger information and/or other relevant data to monitorthe creation, destruction and/or transfer of the Stable Value Tokens toidentify suspicious and/or potentially fraudulent and/or criminalactivity. In embodiments, the fraud management computer system willmonitor activity and compare it to a suspicious activity database. Inembodiments, in the event that suspicious, possibly fraudulent and/orpossibly criminal activity is identified, the fraud management computersystem may generate a report identifying such activity. In embodiments,the report may be provided to the exchange, the administrator and/or thestable value token issuer and/or may be sent to regulatory or lawenforcement authorities. In embodiments, depending on the nature of theactivity identified in the report, action may be taken which mayinclude, but is not limited to, freezing an account, blocking atransaction involving the Stable Value Token on the blockchain and/ormodifying account information, to name a few.

In embodiments, the fraud management computer system may: (1) identifyand assess the full range of fraud-related and similar risk areas,including market manipulation; (2) provide procedures and/or controls toprotect against identified risks; (3) allocate responsibility formonitoring risks; and/or (4) periodically or aperiodically evaluateand/or revise these procedures, controls and/or monitoring processes, toname a few.

In embodiments, as noted above, upon discovery of any wrongdoing orsuspected wrongdoing, the fraud management computer system may generatereports to the appropriate regulatory agency or agencies, including butnot limited to: (1) a report stating all pertinent details known; (2) asupplemental report of any material developments relating to theoriginally reported events; (3) a statement of the actions taken (orproposed to be taken) with respect to such developments; and (4) astatement of changes, if any, in the entities' operations that have beenput in place, or are planned, in order to avoid repetition of similarevents, to name a few.

In embodiments, the fraud management computer system may freeze,temporarily and permanently, the use of and/or access to Stable ValueTokens (SVCoins) and/or fiat currency held or controlled by theexchange, administrator and/or stable value token issuer. Inembodiments, a Stable Value Token and/or fiat currency available onredemption of the Stable Value Token may be forfeited if the StableValue Token is being used for or has been used for illegal activity. Inembodiments, in the event that a legal order or other legal processrequires the exchange, administrator and/or stable value token issuer todo so, any Stable Value Token and/or the fiat currency available uponexchange of the Stable Value Token may be subject to forfeiture to, orseizure by, a law enforcement agency. In embodiments, any Stable ValueToken and/or fiat currency available upon exchange of Stable Value Tokenthat has been subject to freezing, forfeiture to or seizure by a lawenforcement agency, and/or subject to any similar limitation on its use,may be wholly and permanently unrecoverable and unusable and may, inappropriate circumstances, be destroyed.

In embodiments, the administrator may send instructions to modify thetoken supply for one or more particular accounts. For example, the smartcontract may include instructions to pause a transfer. The pausefunction may be a permanent pause, e.g., for a compromised account, atime limited pause, e.g., for 24 hours or 2 days, or a temporary pausewhich requires another instruction to reactivate the account, to name afew. Such a function could be included as an upgrade feature in a newImpl contract, or built into the smart contract to be activated when anauthorized account, e.g., one or more off-line keys call upon the smartcontract to implement the pause functionality, with appropriateparameters.

In embodiments, the administrator may send instructions to rebalance thetoken supply of one or more particular accounts. For example, the smartcontract may include instructions to adjust a token balance in adesignated account, e.g., by raising the balance in the designatedaccount, lowering the balance in the designated account, or transferringsome or all of the tokens in one designated account to one or more otherdesignated accounts. Such a function could be included as an upgradefeature in a new Impl contract, or built into the smart contract to beactivated when an authorized account, e.g., one or more off-line keys,call upon the smart contract to implement the pause functionality, withappropriate parameters.

In embodiments, the Stable Value Token may be embodied in the form of atoken on the Ethereum Blockchain, referred to as a Gemini Dollar token,as illustrated in the exemplary dashboard of FIGS. 15A-15C.

FIG. 15A illustrates an exemplary GUI for an interface with the digitalasset exchange in which a user can deposit/redeem Gemini Dollar tokensinto an public address associated with the digital asset exchange, inexchange for an corresponding amount of fiat in the user's account atthe digital asset exchange. In embodiments, after the registered user ofthe exchange deposits the stable value token into the exchange's publicaddress, the exchange will transfer from the bank account or otheraccount associated with the stable value token, a corresponding amountof fiat, to the bank account associated with the fiat holdings of theuser. In embodiments, the deposited token will then be burnt fromcirculation. In embodiments, the deposited token may instead of beingburnt be redistributed to another customer, but in such case, anappropriate amount of fiat will need to be redeposited into the bankaccount or other stable investment vehicle associated with the stablevalue token.

In embodiments, creation and redemption of the Gemini Dollar tokens maybe made simple to promote usability and encourage adoption. Inembodiments, Gemini Dollar tokens are redeemed or “destroyed” at thetime of deposit into a digital asset exchange. Exchange customers mayexchange Gemini Dollar tokens for U.S. dollars at a 1:1 exchange rate bydepositing Gemini Dollar tokens into their exchange account. The U.S.dollar amount of Gemini Dollar tokens will be credited to the customer'sexchange account balance at the time of deposit.

The process described in FIGS. 17A-17E illustrates an embodiment ofdepositing/redeeming stable value digital asset tokens (i.e. GeminiDollar tokens) in exchange for fiat.

In step S1702 of FIG. 17A, a digital asset exchange computer systemassociated with a digital asset exchange receives and authenticates anaccess request from a first user device associated with a first user.FIG. 17B provides a detailed illustration of an exemplary process forauthenticating the first user that may be used in accordance withexemplary embodiments of step 1702. In embodiments, In step S1702A, thedigital asset exchange computer system receives an authenticationrequest from the first user device. In embodiments, the authenticationrequest includes first user credential information associated with thefirst user.

At step S1702B, the digital asset exchange computer system determinesthat the first user device is authorized to access the digital assetexchange computer system based at least on the first user credentialinformation. In embodiments, the digital asset exchange computer systemmay further determine that the first user is a registered user of thedigital asset exchange. In embodiments, the digital asset exchange maybe licensed by a government regulatory authority.

At step S1702C, the digital asset exchange computer system generatesfirst graphical user interface (GUI) information for displaying a firstgraphical user interface on the first user device. FIG. 15A illustratesan example of such a first graphical user interface. In step S1702D, thedigital asset exchange computer system transmits the first graphicaluser interface information to the first user device.

Referring back to FIG. 17A, in step S1704, the digital asset computersystem obtains a deposit request from the first user device. FIG. 17Cprovides a detailed illustration of an exemplary embodiment of obtaininga deposit request that may be used in accordance with exemplaryembodiments of step 1704. At step S1704A, the digital asset exchangecomputer system receives a first electronic request from the first userdevice. The first electronic request may be to deposit stable valuedigital asset tokens. In embodiments, each stable value digital assettoken is tied to an underlying digital asset which is maintained on adistributed public transaction ledger in the form of a blockchainmaintained by a plurality of geographically distributed computer systemsin a peer-to-peer network in the form of the blockchain network. Inembodiments, the underlying digital asset is ether, and the blockchainis the Ethereum Blockchain. In embodiments, the underlying digital assetis neo and the blockchain is the Neo Blockchain. In embodiments, theunderlying digital asset may be based on other blockchains that providesmart contract functionality.

In step S1704B, in response to receiving the first electronic depositrequest, the digital asset exchange computer system obtains firstaccount balance information of the first user indicating a first amountof available fiat for the first user held by the digital asset exchangeon behalf of the first user. In embodiments, the digital asset exchangecomputer system obtains the first amount of available fiat from a fiataccount ledger database stored on a computer readable member accessibleby the digital asset exchange computer system.

In step S1704C, the digital asset exchange computer system obtains auser specific destination address. The user specific destination addressmay be uniquely associated with the first user. In step S1704D, thedigital asset exchange computer system generates second graphical userinterface information including at least the first account balanceinformation and the user specific destination address. In embodiments,the graphical user interface described in step S1704C may be thegraphical user interface shown in connection with FIG. 15A.

At step 1704E, the digital asset exchange computer system may transmitthe second graphical user interface information to the first userdevice. In embodiments, this may cause the first user device to displaythe graphical user interface shown in connection with FIG. 15A.

In step 1704F, the digital asset exchange computer system may receive asecond electronic deposit request form the first user device. Inembodiments, the second electronic deposit request may comprise atleast: (1) a first amount of stable value digital asset tokens to bedeposited; (2) a designated public address of the first user on theunderlying blockchain from which the first amount of stable valuedigital asset tokens will be transferred; and (3) a digital signaturebased on a designated private key of the first user. In embodiments, thedesignated private key of the first user is mathematically related tothe designated public address of the first user.

In embodiments, the designated private key of the first user may bestored in a custodial system, the custodial system may be part ofdigital asset exchange computer system, the administrator system, thestable value token issuer system or a third party system and may beaccessed to provide the digital signature based on authorization of thefirst user. In embodiments, the first user may authorize transactionsbased on authentication information. In embodiments, the authenticationinformation may include a user name and password associated with thefirst user. In embodiments, multi-fact verification may be necessary inorder for the first user to authorize the custodial system to access thedesignated private key and provide a digital signature to authorize atransaction. In embodiments, the multi-fact verification may include theuse of an authorization code that is sent to a predetermined userdevice, e-mail address, or mobile phone number, to name a few,associated with the first user, for example, as used in AUTHY® (AUTHY®is a registered trademark of Twilio, Inc.). In embodiments, othermulti-factor verifications may be used, such as identification of a userdevice associated with the first user based on phone number or mobilenetwork, location information and shared secret verification, to name afew.

Referring back to FIG. 17A, in step S1706, the digital asset exchangecomputer system processes the second electronic deposit request. FIGS.17D-17E provide a detailed illustration of an exemplary embodiment ofprocessing the second electronic deposit request that may be used inaccordance with exemplary embodiments of step 1706. Referring to FIG.17D, in step S1706A, the digital asset exchange computer systemcalculates a second amount of fiat based on the first amount of stablevalue digital asset tokens. In embodiments, the second amount of fiat isdetermined using a fixed predetermined ratio of stable value digitalasset tokens to fiat. In embodiments, the fiat is U.S. Dollars. In theembodiments where the fiat is U.S. Dollars, the fixed predeterminedratio may be one stable value digital asset token is equal to one U.S.Dollar. In embodiments, the fixed predetermined ratio may be one hundredstable value digital asset tokes is equal to one U.S. Dollar.

In step S1706B, the digital asset exchange computer system determinesthat the first amount of stable value digital asset tokens is present atthe designated public address of the first user. In the case where thefirst amount of stable value digital asset tokens is present at thedesignated public address of the first user, as indicated in stepS1706C, the digital asset exchange computer system determines a thirdamount of fiat associated with an updated amount of available fiat ofthe first user. In embodiments, the third amount of fiat equals thefirst amount of available fiat of the first user plus the second amountof fiat.

At step 1706D, the digital asset computer system updates the fiataccount ledger to reflect that the updated amount of available fiat ofthe first user is the third amount of fiat. At a step 1706E, the digitalasset exchange computer system generates a first transaction request forthe blockchain from a first digital asset exchange public key address onthe blockchain to a first contract address associated with a stablevalue token issuer. In embodiments, the first digital asset exchangepublic key address is mathematically related to a first digital assetexchange private key which is stored in the computer readable memberaccessible by the digital asset exchange computer system.

In embodiments, the first transaction request includes: (1) a request toobtain the first amount of stable value digital asset tokens from thedesignated public address of the first user; and (2) a request todestroy the first amount of stable value digital asset tokens. Inalternative embodiments, the first transaction request may include: (1)a request to obtain the first amount of stable value digital assettokens from the designated public address of the first user; and (2) arequest to provide the first amount of stable value digital asset tokensto a specific destination address. In embodiments, the first transactionrequest is signed with a generated digital signature based on thedigital asset exchange private key of the digital asset exchange.

In step 1706F, the digital asset exchange computer system may update astable value digital asset token issuer fiat ledger. The update maydecrease the balance of fiat by the second amount of fiat. Inembodiments, the digital asset exchange computer system may transfer thesecond amount of fiat from a stable value digital asset token issuer toa digital asset exchange fiat account. In embodiments, the digital assetexchange computer system may periodically transfer fiat between a stablevalue digital asset token issuer fiat account and a digital assetexchange fiat account based on net transactions over a predeterminedperiod of time.

At step S1706G, the digital asset exchange computer system may transmitthe first transaction request to the blockchain network via theInternet. In step, S1706H, the digital asset exchange system confirms,via reference to the blockchain, that the first amount of stable valuedigital asset tokens are not present at the designated public address ofthe first user.

FIG. 15B illustrates an exemplary GUI for an interface with the digitalasset exchange in which a user can withdraw/purchase stable value tokensin the form of Gemini Dollar tokens from their digital asset exchangeaccount. In this exemplary embodiment, the amount of the withdrawal isexpressed in U.S. Dollars, and a corresponding amount of U.S. Dollars isdebited from the user's fiat account with the exchange. As part of thewithdrawal process, the digital asset exchange may arrange to issue newstable value tokens to the customer at the specified digital assetexchange in accordance with embodiments elsewhere described. Inembodiments, the digital asset exchange may instead transferpre-existing stable value tokens instead. As noted above, since thestable value token is pegged to a predetermine ratio of fiat, (e.g., 1Gemini Dollar=USD 1, or 100 Gemini Dollar=USD 1), expressing thewithdrawal amount in dollars is sufficient to allow the user and thedigital asset system to determine the amount of Gemini Dollars tokensbeing withdrawn/purchased.

FIGS. 16A-16E illustrate an embodiment of withdrawing/purchasing stablevalue digital asset tokens (i.e. Gemini Dollar tokens) in exchange forfiat.

In step S1602 of FIG. 16A, a digital asset exchange computer systemassociated with a digital asset exchange receives and authenticates anaccess request from a first user device associated with a first user.FIG. 16B provides a more detailed illustration of an exemplaryembodiment of receiving and authenticating an access request from afirst user device associated with a first user that may be used inaccordance with exemplary embodiments of step 1602. At step S1602A, thedigital asset exchange computer system receives an authenticationrequest from the first user device. In embodiments, the authenticationrequest includes first user credential information associated with thefirst user.

At step S1602B, the digital asset exchange computer system determinesthat the first user device is authorized to access the digital assetexchange computer system based at least on the first user credentialinformation. In embodiments, the digital asset exchange computer systemmay further determine that the first user is a registered user of thedigital asset exchange. In embodiments, the digital asset exchange maybe licensed by a government regulatory authority.

At step S1602C, the digital asset exchange computer system generatesfirst graphical user interface (GUI) information for displaying a firstgraphical user interface on the first user device. In step S1602D, thedigital asset exchange computer system transmits the first graphicaluser interface information to the first user device.

Referring back to FIG. 16A, in step S1604, the digital asset computersystem obtains a withdraw request from the first user device. FIG. 16Cprovides a detailed illustration of an exemplary process of obtainingthe withdraw request that may be used in accordance with exemplaryembodiments of step 1604. In step S1604A, the digital asset exchangecomputer system receives a first electronic request to withdraw stablevalue digital asset tokens from the first user device. In embodiments,the stable value digital asset token is tied to an underlying digitalasset which is maintained on a distributed public transaction ledger inthe form of a blockchain maintained by a plurality of geographicallydistributed computer systems in a peer-to-peer network in the form ofthe blockchain network. In embodiments, the underlying digital asset isether and the blockchain is the Ethereum Blockchain. In embodiments, theunderlying digital asset is neo and the blockchain is the NeoBlockchain.

In step S1604B, the digital asset exchange computer system obtains firstaccount balance information of the first user indicating a first amountof available fiat for the first user held by the digital asset exchangeon behalf of the user. The digital asset exchange computer system mayobtain the first account balance from a fiat account ledger databasestored on computer readable member accessible by the digital assetexchange computer system.

In step S1604C, the digital asset exchange computer system generatessecond graphical user interface information including at least the firstaccount balance information. In embodiments, the second graphical userinterface may be similar to the graphical user interface shown inconnection with FIG. 15B. In step S1604D, the digital asset exchangecomputer system transmits the second graphical user interfaceinformation to the first user device. In embodiments, the first userdevice may display the second graphical user interface in response tothis transmission. For example, the first user device may display thegraphical user interface shown in connection with FIG. 15B.

In step S1604E, the digital asset exchange computer system receives asecond electronic withdrawal request from the first user device. Thesecond electronic withdrawal request may comprise at least: (1) a firstamount of stable value digital asset tokens to be withdrawn; and (2) adestination public address on the underlying blockchain to transfer thefirst amount of stable value digital asset tokens.

Referring back to FIG. 16A, in step S1606, the digital asset exchangecomputer system processes the second withdrawal request. FIGS. 16D-16Eprovide a detailed illustration of an exemplary process of processingthe second withdrawal request that may be used In embodiments, of stepS1606. In step S1606A, the digital asset exchange computer systemcalculates a second amount of fiat based on the first amount of stablevalue digital asset tokens. The second amount of fiat may be determinedusing a fixed predetermined ratio of stable value digital asset tokensto fiat. In embodiments, the fiat is U.S. Dollars. In the embodimentswhere the fiat is U.S. Dollars, the fixed predetermined ratio may be onestable value digital asset token is equal to one U.S. Dollar. Inembodiments, the ratio may be one hundred stable value digital assettokes is equal to one U.S. Dollar.

At step S1606B, the digital asset exchange computer system determinesthat the second amount of fiat is less than the first amount ofavailable fiat of the first user. In step 1606C, where the second amountof fiat is less than the first amount of available fiat of the firstuser, the digital asset exchange computer system determines a thirdamount of fiat associated with an updated amount of available fiat ofthe first user. In embodiments, the third amount of fiat equals thefirst amount of available fiat of the first user less the second amountof fiat.

In step S1606D, the digital asset exchange computer system updates thefiat ledger database to reflect the updated amount of available fiat. Instep S1606E, the digital asset exchange computer system updates a stablevalue digital asset token issuer fiat ledger, increasing the balance offiat by the second amount of fiat. In embodiments, the digital assetexchange computer system may transfer the second amount of fiat from adigital asset exchange fiat account to a stable value digital assettoken issuer fiat account. In embodiments, the digital asset exchangecomputer system may periodically transfer fiat between the digital assetexchange fiat account and the stable value digital asset token issuerfiat account.

In step S1606F, the digital asset exchange computer system generates afirst transaction request for the blockchain network from a firstdigital asset exchange public key address on the blockchain to a firstcontract address associated with a stable value digital asset tokenissuer. In embodiments, the first digital asset exchange public key ismathematically related to a first digital asset exchange private keywhich is stored in the computer readable member accessible by thedigital asset exchange computer system. The first transaction requestmay comprise a first message including a request to obtain in the firstdesignated public address the first amount of stable value digital assettokens. In embodiments, the first transaction request is signed with adigital signature generated using at least the digital asset exchangeprivate key. In embodiments, the request to obtain may further include arequest to generate the first amount of stable value digital assettokens at the first designated public address of the first user. Inembodiments, the request to obtain may include a request to transfer thefirst amount of stable value digital asset tokens from a stable valuedigital asset token issuer public address to the first designated publicaddress of the first user.

In step S1606G of FIG. 16E, the digital asset exchange computer systemtransmits the first transaction request to the blockchain network viathe Internet. In step S1606H, the digital asset exchange computer systemconfirms, via reference to the blockchain, that the balance of stablevalue digital asset tokens in the first designated public address of thefirst user includes the first amount of stable value digital assettokens.

In embodiments, as noted above, customers may exchange U.S. dollars forGemini Dollar tokens at a 1:1 exchange rate, for example, by initiatinga withdrawal of Gemini Dollar tokens from their digital asset exchangeaccount to any Ethereum address they specify, as indicated in FIG. 15B.The U.S. dollar amount of Gemini Dollar tokens will be debited from thecustomer's exchange account balance at the time of withdrawal.

In embodiments, as illustrated in FIG. 15C, for example, the exemplarydashboard may also allow the user an opportunity to cancel a transactionbefore final execution by the blockchain network and inclusion on theunderlying blockchain.

In Step S1002 of FIG. 10, for example, Alice's wallet, or associateddigital asset address, may send a request message to the databasemaintained by the blockchain including: (a) Alice's digital signature,which is based on Alice's private key which corresponds to her publickey which is associated with her ethereum digital asset address (herpublic address), which is typically associated with a digital wallet(Source Address); (b) token identification information; (c) amount oftoken to be transferred; and (d) Bob's ethereum digital asset address(Destination Address). In embodiments, if a fee is charged for thetransaction, fee payment information may also be required and provided.For example, on the Ethereum network, an amount of Gas tokens may berequired from the sender to pay for processing of the transaction into ablock on the blockchain. In embodiments, the message may include aproposed fee amount and/or fee proposal including a limit in e.g., Gas.The request message will also be digitally signed by Alice's privatekey.

In Step S1004, when miners on the blockchain network receive thetransaction request directed to the contract wallet or associateddigital asset address, with the request message, miners on theblockchain network will confirm the transaction, including verifyingthat the message was properly signed by Alice's digital signature. InStep S1004-b, the miners may verify that Alice has sufficient amount oftokens to perform the requested transaction, for example, by comparingAlice's balance against Alice's token balance as indicated on theblockchain. In Step S1004-c, the validity of Bob's digital asset address(the Destination Address) may also be confirmed by the miners. Theminers may also compare the request with smart contract coding andinstructions included in the Contract Address. The transaction feediscussed above is paid to the miners for confirming the transaction asnoted above.

In Step S1006, if the request is verified the transaction is publishedin the Security Token database of the blockchain reflecting a debitagainst Alice's token holdings and a corresponding credit to Bob's tokenholdings (less any applicable fees).

In Step S1008, response messages to the digital asset addresses of bothAlice and Bob may be sent to reflect that the transaction wassuccessfully processed. In embodiments, such messages may includeinformation including: (i) the source digital asset address; (ii) thedestination digital asset address; (iii) the amount of tokenstransferred; and/or (iv) the new balances for each digital asset addressor associated digital wallet. In embodiments, the message may include aproposed fee amount and/or fee proposal including a limit in e.g., Gas.In embodiments, Alice, Bob, and/or third parties may view the balancesand transaction information based on the information stored in theblockchain, by, e.g., viewing token balances at websites likeetherscan.io, to name a few.

In contrast to tokens, a blockchain based digital asset (such as ether)is hard coded into the blockchain (e.g., the Ethereum Blockchain)itself. It is sold and traded as a cryptocurrency, and it also powersthe network (e.g., the Ethereum Network) by allowing users to pay forsmart contract transaction fees. In some networks, transactions fees maybe paid for in digital assets, such as tokens (e.g., Gas) or blockchainbased digital assets (e.g., bitcoin). In the Ethereum Network, allcomputations typically have a cost based on other digital assets, suchas Gas.

In embodiments, when tokens are sent to or from a Contract Address, forexample, a fee may be charged for that transaction (in this case, arequest to the token's contract to update its database) in, e.g., someform of digital asset, such as ether, bitcoin, Gas, to name a few. Inembodiments, the message may include a proposed fee amount and/or feeproposal including a limit in digital asset, e.g., ether, bitcoin orGas. This payment is then collected by a miner who confirms thetransaction in a block, which then gets added to the blockchain.

FIG. 2 is an exemplary screen shot of an excerpt of a bitcointransaction log or transaction ledger 115 showing digital asset accountidentifiers (e.g., addresses) corresponding to origin and destinationaccounts for each transaction and amount information for eachtransaction in accordance with exemplary embodiments of the presentinvention. The exemplary log 115 includes transaction identifiers, dateand/or time information, fee information, digital asset accountidentifiers for the origin accounts, digital asset account identifiersfor the destination accounts, and amounts transferred to and from eachaccount. Such a ledger may also include description information (such asnotes describing a transaction, e.g. “rent payment”) and/or balanceinformation, to name a few. Other forms of transaction logs can be usedconsistent with exemplary embodiments of the present invention. In anexemplary embodiment, the description information may be included as amessage in a request for a transaction. The description informationdiscussed above thus may also be used to confirm control of over aparticular account.

As can be seen in FIG. 2, digital asset transfers may begin from asingle origin and be sent to a single destination or multipledestinations. Similarly, digital assets may be transferred from multipleorigins to one or more destinations.

FIG. 2A illustrates a screenshot showing an exemplary embodiment of atoken ledger for a Gas token. This particular screenshot shows aspecific example the token ledger for the Gas token provided byetherscan.io. As illustrated the ledger illustrates, in chronologicalorder, a series of transactions identifying the source address 2202 anddestination address 2204 along with the quantity of tokens 2206transferred in each transaction. In embodiments, the Security Tokenledger of the present application may be similar to that illustrated inFIG. 2A. In embodiments, as illustrated in FIG. 2A, the Security Tokenledger may also include the option to identify all Token holders 2208 aswell as options to view token details 2210 and to view the contractdetails 2012. Similarly, in embodiments, an SVCoin Token ledger of thepresent application may be similar to that illustrated in FIG. 2A.Digital asset ledgers may be maintained in the form of a database. Sucha database may be maintained on a blockchain or off a blockchain as asidechain which may later be published to the blockchain.

An exemplary embodiment of a digital asset network is illustrated inFIG. 1. In embodiments, other digital math-based assets can bemaintained and/or administered by other digital math-based assetnetworks. Without meaning to limit the invention, a digital math-basedasset network will be discussed with reference to a Bitcoin network byexample. Of course, other digital asset networks, such as the Ethereumnetwork can be used with embodiments of the present invention. A digitalmath-based asset network, such as a Bitcoin network, may be an on-line,end-user to end-user network hosting a public transaction ledger 115 andgoverned by source code 120′ comprising cryptologic and/or algorithmicprotocols. A digital asset network can comprise a plurality of endusers, a . . . N, each of which may access the network using one or morecorresponding user device 105 a, 105 b, . . . 105N. In embodiments, userdevices 105 a, 105 b, . . . 105N may be operatively connected to eachother through a data network 125, such as the Internet, a wide areanetwork, a local area network, a telephone network, dedicated accesslines, a proprietary network, a satellite network, a wireless network, amesh network, or through some other form of end-user to end-userinterconnection, which may transmit data and/or other information. Anyparticipants in a digital asset network may be connected directly orindirectly, as through the data network 125, through wired, wireless, orother connections.

In the exemplary embodiment, user devices 105 a, 105 b, . . . 105N caneach run a digital asset client 110, e.g., a Bitcoin client, which cancomprise digital asset source code 120 and an electronic transactionledger 115. The source code 120 can be stored in processor readablememory, which may be accessed by and/or run on one or more processors.The electronic transaction ledger 115 can be stored on the same and/ordifferent processor readable memory, which may be accessible by the oneor more processors when running the source code 120. In embodiments, theelectronic transaction ledger 115 a (contained on a user device 105 a)should correspond with the electronic transaction ledgers 115 b . . .115N (contained on user devices 105 b . . . 105N), to the extent thatthe corresponding user device has accessed the Internet and been updated(e.g., downloaded the latest transactions). Accordingly, the electronictransaction ledger may be a public ledger. Exemplary embodiments ofdigital asset clients 110 for the Bitcoin network (Bitcoin clients)include Bitcoin-Qt and Bitcoin Wallet, to name a few.

In embodiments, some of the transactions on the public ledger may beencrypted or otherwise shielded so that only authorized users may accessledger information about such transactions or wallets.

In addition, a digital asset network, such as a Bitcoin network, mayinclude one or more digital asset exchange 130, such as Bitcoinexchanges (e.g., BitFinex, BTC-e). Digital asset exchanges may enable orotherwise facilitate the transfer of digital assets, such as bitcoin,and/or conversions involving digital assets, such as between differentdigital assets and/or between a digital asset and non-digital assets,currencies, to name a few. The digital asset network may also includeone or more digital asset exchange agents 135, e.g., a Bitcoin exchangeagent. Exchange agents 135 may facilitate and/or accelerate the servicesprovided by the exchanges. Exchanges 130, transmitters 132, and/orexchange agents 135 may interface with financial institutions (e.g.,banks) and/or digital asset users. Transmitters 132 can include, e.g.,money service businesses, which could be licensed in appropriategeographic locations to handle financial transactions. In embodiments,transmitters 132 may be part of and/or associated with a digital assetexchange 130. Like the user devices 105, digital asset exchanges 130,transmitters 132, and exchange agents 135 may be connected to the datanetwork 125 through wired, wireless, or other connections. They may beconnected directly and/or indirectly to each other and/or to one or moreuser device 105 or other entity participating in the digital assetsystem.

Digital assets may be sub-divided into smaller units or bundled intoblocks or baskets. For example, for bitcoin, subunits, such as aSatoshi, as discussed herein, or larger units, such as blocks ofbitcoin, may be used in exemplary embodiments. Each digital asset, e.g.,bitcoin, may be subdivided, such as down to eight decimal places,forming 100 million smaller units. For at least bitcoin, such a smallerunit may be called a Satoshi. Other forms of division can be madeconsistent with embodiments of the present invention.

In embodiments, the creation and transfer of digital math-based assetscan be based on an open source mathematical and/or cryptographicprotocol, which may not be managed by any central authority. Digitalassets can be transferred between one or more users or between digitalasset accounts and/or storage devices (e.g., digital wallets) associatedwith a single user, through a network, such as the Internet, via acomputer, smartphone, or other electronic device without an intermediatefinancial institution. In embodiments, a single digital assettransaction can include amounts from multiple origin accountstransferred to multiple destination accounts. Accordingly, a transactionmay comprise one or more input amounts from one or more origin digitalasset accounts and one or more output amounts to one or more destinationaccounts. Origin and destination may be merely labels for identifyingthe role a digital asset account plays in a given transaction; originand destination accounts may be the same type of digital asset account.

In embodiments, a digital math-based asset system may produce digitalasset transaction change. Transaction change refers to leftover digitalasset amounts from transactions in digital asset systems, such asBitcoin, where the transactions are comprised of one or more digitalinputs and outputs. A digital asset account can store and/or trackunspent transaction outputs, which it can use as digital inputs forfuture transactions. In embodiments, a wallet, third-party system,and/or digital asset network may store an electronic log of digitaloutputs to track the outputs associated with the assets contained ineach account. In digital asset systems such as Bitcoin, digital inputsand outputs cannot be subdivided. For example, if a first digital assetaccount is initially empty and receives a transaction output of 20 BTC(a bitcoin unit) from a second digital asset account, the first accountthen stores that 20 BTC output for future use as a transaction input. Tosend 15 BTC, the first account must use the entire 20 BTC as an input,15 BTC of which will be a spent output that is sent to the desireddestination and 5 BTC of which will be an unspent output, which istransaction change that returns to the first account. An account withdigital assets stored as multiple digital outputs can select anycombination of those outputs for use as digital inputs in a spendingtransaction. In embodiments, a digital wallet may programmaticallyselect outputs to use as inputs for a given transaction to minimizetransaction change, such as by combining outputs that produce an amountclosest to the required transaction amount and at least equal to thetransaction amount.

Referring again to FIG. 1, a digital asset network may include digitalasset miners 145. Digital asset miners 145 may perform operationsassociated with generating or minting new digital assets, and/oroperations associated with confirming transactions, to name a few.Digital asset miners 145 may collaborate in one or more digital assetmining pools 150, which may aggregate power (e.g., computer processingpower) so as to increase output, increase control, increase likelihoodof minting new digital assets, increase likelihood of adding blocks to ablockchain, to name a few.

In embodiments, the processing of digital asset transactions, e.g.,bitcoin transactions, can be performed by one or more computers over adistributed network, such as digital asset miners 145, e.g., bitcoinminers, and/or digital asset mining pools 150, e.g., bitcoin miningpools. In embodiments, mining pools 150 may comprise one or more miners145, which miners 145 may work together toward a common goal. Miners 145may have source code 120′, which may govern the activities of the miners145. In embodiments, source code 120′ may be the same source code asfound on user devices 105. These computers and/or servers cancommunicate over a network, such as an internet-based network, and canconfirm transactions by adding them to a ledger 115, which can beupdated and archived periodically using peer-to-peer file sharingtechnology. For example, a new ledger block could be distributed on aperiodic basis, such as approximately every 10 minutes. In embodiments,the ledger may be a blockchain. Each successive block may recordtransactions that have occurred on the digital asset network. Inembodiments, all digital asset transactions may be recorded asindividual blocks in the blockchain. Each block may contain the detailsof some or all of the most recent transactions that are not memorializedin prior blocks. Blocks may also contain a record of the award ofdigital assets, e.g., bitcoin, to the miner 145 or mining pool 150 whoadded the new block, e.g., by solving calculations first.

A miner 145 may have a calculator 155, which may solve equations and/oradd blocks to the blockchain. The calculator 155 may be one or morecomputing devices, software, or special-purpose device, to name a few.In embodiments, in order to add blocks to the blockchain, a miner 145may be required to map an input data set (e.g., the blockchain, plus ablock of the most recent transactions on the digital asset network,e.g., transactions on the Bitcoin network, and an arbitrary number, suchas a nonce) to a desired output data set of predetermined length, suchas a hash value. In embodiments, mapping may be required to use one ormore particular cryptographic algorithms, such as the SHA-256cryptographic hash algorithm or scrypt, to name a few. In embodiments,to solve or calculate a block, a miner 145 may be required to repeatthis computation with a different nonce until the miner 145 generates aSHA-256 hash of a block's header that has a value less than or equal toa current target set by the digital asset network. In embodiments, eachunique block may only be solved and added to the blockchain by one miner145. In such an embodiment, all individual miners 145 and mining pools150 on the digital asset network may be engaged in a competitive processand may seek to increase their computing power to improve theirlikelihood of solving for new blocks. In embodiments, successful digitalasset miners 145 or mining pools 150 may receive an incentive, such as,e.g., a fixed number of digital assets (e.g., bitcoin) and/or atransaction fee for performing the calculation first and correctlyand/or in a verifiable manner.

In embodiments, the cryptographic hash function that a miner 145 usesmay be one-way only and thus may be, in effect, irreversible. Inembodiments, hash values may be easy to generate from input data, suchas valid recent network transaction(s), blockchain, and/or nonce, butneither a miner 145 nor other participant may be able to determine theoriginal input data solely from the hash value. Other digital assetnetworks may use different proof of work algorithms, such as asequential hard memory function, like scrypt, which may be used forLitecoin. As a result, generating a new valid block with a header lessthan the target prescribed by the digital asset network may be initiallydifficult for a miner 145, yet other miners 145 can easily confirm aproposed block by running the hash function at least once with aproposed nonce and other identified input data. In embodiments, aminer's proposed block may be added to the blockchain once a definedpercentage or number of nodes (e.g., a majority of the nodes) on thedigital asset network confirms the miner's work. A miner 145 may have averifier 160, which may confirm other miners' work. A verifier 160 maybe one or more computers, software, or specialized device, to name afew. A miner 145 that solved such a block may receive the reward of afixed number of digital assets and/or any transaction fees paid bytransferors whose transactions are recorded in the block. “Hashing” maybe viewed as a mathematical lottery where miners that have devices withgreater processing power (and thus the ability to make more hashcalculations per second) are more likely to be successful miners 145. Inembodiments, as more miners 145 join a digital asset network and asprocessing power increases, the digital asset network may adjust thecomplexity of the block-solving equation to ensure that onenewly-created block is added to the blockchain approximately every tenminutes. Digital asset networks may use different processing times,e.g., approximately 2.5 minutes for Litecoin, approximately 10 minutesfor Bitcoin, to name a few.

In addition to archiving transactions, a new addition to a ledger cancreate or reflect creation of one or more newly minted digital assets,such as bitcoin. In embodiments, new digital math-based assets may becreated through a mining process, as described herein. In embodiments,the number of new digital assets created can be limited. For example, inembodiments, the number of digital assets (e.g., bitcoin) minted eachyear is halved every four years until a specified year, e.g., 2140, whenthis number will round down to zero. At that time no more digital assetswill be added into circulation. In the exemplary embodiment of bitcoin,the total number of digital assets will have reached a maximum of 21million assets in denomination of bitcoin. Other algorithms for limitingthe total number of units of a digital math-based asset can be usedconsistent with exemplary embodiments of the present invention. Forexample, the Litecoin network is anticipated to produce 84 millionLitecoin. In embodiments, the number of digital assets may not be cappedand thus may be unlimited. In embodiments, a specified number of coinsmay be added into circulation each year, e.g., so as to create a 1%inflation rate.

In embodiments, the mining of digital assets may entail solving one ormore mathematical calculations. In embodiments, the complexity of themathematical calculations may increase over time and/or may increase ascomputer processing power increases. In embodiments, result of solvingthe calculations may be the addition of a block to a blockchain, whichmay be a transaction ledger, as described further below. Solving thecalculations may verify a set of transactions that has taken place.Solving the calculations may entail a reward, e.g., a number of digitalmath-based assets and/or transaction fees from one or more of theverified transactions.

Different approaches are possible for confirming transactions and/orcreating new assets. In embodiments, a digital asset network may employa proof of work system. A proof of work system may require some type ofwork, such as the solving of calculations, from one or more participants(e.g., miners 145) on the network to verify transactions and/or createnew assets. In embodiments, a miner 145 can verify as many transactionsas computationally possible. A proof of work system may becomputationally and/or energy intensive. In embodiments, the network maylimit the transactions that a miner 145 may verify.

In embodiments, a digital asset network may employ a proof of stakesystem. In a proof of stake system, asset ownership may be tied totransaction verification and/or asset creation. Asset ownership caninclude an amount of assets owned and/or a duration of ownership. Theduration of ownership may be measured linearly as time passes while auser owns an asset. In an exemplary embodiment, a user holding 4% of alldigital assets in a proof of stake system can generate 4% of all blocksfor the transaction ledger. A proof of stake system may not require thesolution of complex calculations. A proof of stake system may be lessenergy intensive than a proof of work system. In embodiments, a hybridof proof of work and proof of stake systems may be employed. Forexample, a proof of work system may be employed initially, but as thesystem becomes too energy intensive, it may transition to a proof ofstake system.

Proof or work and proof of stake are both examples of consensusalgorithms. Such consensus algorithms have as their goal providing amethod of reaching consensus to improve the system whether it be on waysof improving transactions, upgrading the network, etc.

In embodiments, asset creation and/or transaction confirmation can begoverned by a proof of stake velocity system. Proof of stake velocitymay rely upon asset ownership where the function for measuring durationof ownership is not linear. For example, an exponential decay timefunction may ensure that assets more newly held correspond to greaterpower in the system. Such a system can incentivize active participationin the digital math-based asset system, as opposed to storing assetspassively.

In embodiments, a proof of burn system may be employed. Proof of burnmay require destroying assets or rendering assets unspendable, such asby sending them to an address from which they cannot be spent.Destroying or rendering assets unusable can be an expensive task withinthe digital math-based asset system, yet it may not have external costssuch as the energy costs that can be associated with mining in a proofof work system.

Blockchains can include a consensus generating protocol through whichthe network determines whether a transaction is valid, included in theledger and in what order each transaction should be included. Examplesof such facilities may include mining, proof of work, proof of stakeprotocols, to name a few.

Stable Value Digital Asset Token

In embodiments, a stable value digital asset token, or Stable ValueToken (“SVCoin”) may operate on a blockchain based network, such as theEthereum network, a decentralized virtual currency and blockchainnetwork with a programming language that can automatically facilitate,verify, and enforce the terms of a digital contract entered into byhuman or computer counterparties. In embodiments, the SVCoin may conformwith the ERC-223 token standard, making it available for a variety ofuses within the Ethereum Network. In embodiments, the SVCoin may conformto the ERC-721 token standard. However, unlike other types ofcryptocurrencies currently available on the Ethereum Network or thevirtual currency ecosystem generally, the SVCoin will be strictly peggedto a fiat currency, such as the U.S. Dollar, and a custodian, such as atrusted entity like a digital asset exchange or bank, to name a few,will hold an equal value in fiat (e.g., one (1) SVCoin is pegged to beequal to one (1) USD or one hundred (100) SVCoin is pegged to equal one(1) USD, to name a few). In embodiments, periodic or aperiodicreconciliations may be performed to confirm that the amount of fiatcurrency held by the trusted entity corresponds to the number of SVCoins(Stable Value Tokens) held on the public ledger. In embodiments, thereconciliation may account for the fact that SVCoins (Stable ValueTokens) may have been created but not yet distributed to third parties.

In embodiments, a digital asset exchange, such as a regulated digitalasset exchange, like Gemini, may be the sole issuer of the SVCoin. Inembodiments, especially in the context of a regulated digital assetexchange, in order to obtain freshly minted SVCoin, customers must firstregister with the digital asset exchange and create an exchange accountto allow access to the digital asset exchange platform. Customers maydeposit fiat (e.g., USD) with the digital asset exchange, via, e.g.,Fedwire, ACH, Swift, to name a few, into the customers respectiveexchange account, or convert into fiat some or all of existing digitalassets held at the digital asset exchange. SVCoin may be held in thecustomer's exchange account or may be transferred via the blockchain,such as via the Ethereum Network. In embodiments, the SVCoin issuer maybe a digital asset exchange, a bank, a trust or some other trustedentity, to name a few.

In embodiments, regardless of whether the SVCoin is stored in thecustomer's exchange account or transferred via the blockchain such asthe Ethereum Network, the digital exchange will continue to holdsufficient fiat to maintain the total value of SVCoin based on anotional pegged rate (e.g., one USD for every one SVCoin issued). Inembodiments, the value of the SVCoin is pegged to the fiat in a fixedproportion, for example 1:1. In embodiments, fiat will be held in asegregated, omnibus bank account at one or more federally insureddepository institution. In embodiments, the fiat may be held in othersecure and non-volatile financial instruments, such as invested intreasury bills or other liquid, interest bearing financial instruments.

In embodiments, customers wishing to redeem their SVCoin for fiat may doso through the digital asset platform. Customers that have transferredtheir SVCoin to the blockchain will be able to transfer their SVCoinback to their exchange account, and subsequently redeem them for fiatthrough the digital exchange platform, such as via Fedwire, ACH or SWIFTto the customer's registered bank account, to name a few. For each fiatredeemed with the digital exchange, a corresponding SVCoin will beremoved from circulation. As mentioned above, exemplary embodiments ofsuch transactions are discussed below in connection with the descriptionof FIGS. 11A-1-4, 11B-1-4, and 11C-1-2.

In embodiments, the Stable Value Token may be implemented as a token onthe Ethereum blockchain, following the open standard known as ERC20adopted by the Ethereum community. In embodiments, the Stable ValueToken may be a system of smart contracts. In embodiments, the StableValue Token may be a triplet of smart contracts on the Ethereumblockchain, which may be referred to as ‘Proxy’, ‘Impl’, and ‘Store’.

In embodiments, the smart contract known as ‘Proxy’ is the permanent andpublic face of the Stable Value Token and provides the interface tointeract with the token to allow token holders transfer their tokens andview token balances. In embodiments, however, this contract containsneither the code nor the data that comprises the behavior and state ofthe Stable Value Token.

In embodiments, the ‘Proxy’ contract delegates to the contract known as‘Impl’ authority to execute the logic that governs token transfers,issuance, and other core features. In embodiments, ‘Impl’ does notdirectly own the data that is the ledger of the Stable Value Token, themapping of token holders to their balances, but instead delegates thisto the smart contract known as ‘Store’.

In embodiments, the arrangement of ‘Proxy’, ‘Impl’, and ‘Store’ providesfor future change and flexibility. While ‘Proxy’ may be the permanentaddress of the Stable Value Token on the Ethereum blockchain, and‘Store’ is the external storage of the token ledger, the ‘Impl’ contractis designed to be replaced, if need be. Utilizing this architecture toimplement the Stable Value Token provides for the following advantages:

-   -   1. allows for responding to security incidents and resolving        vulnerabilities;    -   2. allows for extending the system with new features;    -   3. allows for adding later optimizations to improve the        operational efficiency of the token; and    -   4. In extreme cases and when compelled to do so, allows for        pause, block, or reverse token transfers.

In embodiments, each of these three contracts may be a custodian: anactor in the system that has the sole authority to authorize importantactions. In embodiments, the custodianship role varies for each of‘Proxy’, ‘Impl’, and ‘Store’. In embodiments, the custodian of ‘Proxy’can redirect the delegation to the active token implementation, thespecific ‘Impl’ contract. In embodiments, matching this arrangement, the‘Store’ contract may only accept updates to its ledger from a singletrusted source, the active token implementation, the specific ‘Impl’contract. In embodiments, these two custodial actions on ‘Proxy’ and‘Store’ provide the upgrade feature where a new ‘Impl’ displaces theprior version by the custodian of ‘Proxy’ redirecting the delegation in‘Proxy’; and a new ‘Impl’ displaces the prior version by the custodianof ‘Store’ updating the trusted caller of ‘Store’. In embodiments, thecustodians of ‘Proxy’ and ‘Store’ can also pass custodianship to newcustodians.

In embodiments, the primary custodial action on the ‘Impl’ contract isdifferent. In embodiments, an important aspect of the Stable ValueTokens is governing the increase to the token supply since at all timesthe system must ensure that there are at least as many U.S. Dollars asthere are Stable Value Tokens in circulation. In embodiments, the ‘Impl’contract contains the logic to increase the token supply, and thecustodian of ‘Impl’ has the sole authority to invoke it. In embodiments,custodianship can also be passed.

In embodiments, an auxiliary contract is a contract to fulfill thecustodian role, which we will refer to here as ‘Custodian’. Inembodiments, this contract is designed around several securityprinciples:

-   -   1. Dual Control: actions by the ‘Custodian’ contract are        initially locked, and pending actions will only proceed once two        out of a set of designated signers approve the action. (Approval        is a digital signature linked to the action instructions, e.g.        the amount and destination of new tokens.)    -   2. Offline Control: the ‘Custodian’ contract is designed with        the expectation that the set of designated signers are keys        managed by offline (“air gapped”) computer systems.    -   3. Time Locks: actions by the ‘Custodian’ contract are locked        not only pending approval from two signers, but also require the        passage of a minimum period of time before they can be executed.        This enables the effective use of intrusion detection systems        and a window of opportunity to respond to security breaches.    -   4. Revocation: pending actions can be revoked; thus erroneous or        malicious actions can be nullified while they are still pending.

This provides strong security control on custodianship, which isappropriate for the critical and infrequent system actions of replacingthe ‘Impl’ contract (“the upgrade feature”) and passing custodianship.In embodiments, however, for the action of increasing the token supply,an action expected to occur frequently, using ‘Custodian’ as thecustodian of ‘Impl’ introduces an undue operational burden.

In embodiments, a second auxiliary contract, is referred to as‘PrintLimiter’. In embodiments, the purpose of the ‘PrintLimiter’ smartcontract is to govern the increases to the supply of Stable ValueTokens, specifically by a hybrid of online and offline control. While‘Custodian’ is the custodian of the contracts ‘Proxy’ and ‘Store’, the‘PrintLimiter’ contract is the custodian of ‘Impl’, and in turn,‘Custodian’ is the custodian of ‘PrintLimiter’. In embodiments, thisdoubly-layered custodianship relationship still reserves ultimatecontrol to ‘Custodian’, however, the ‘PrintLimiter’ contract grantslimited permission to increase the token supply (“print” new tokens) toa key in online control (an automated, networked computer system), whichwe will refer to as ‘printer’. In embodiments, the ‘printer’ key canincrease the token supply in response to user demand to withdraw U.S.dollars as Stable Value Tokens, but only up until a ceiling. Inembodiments, further expansion of the supply is disallowed by‘PrintLimiter’ once the ceiling is reached. In embodiments, increasingthe ceiling is an action reserved for the custodian, and the custodianof ‘PrintLimiter’ is ‘Custodian.’ In embodiments, the ‘printer’ canreduce the ceiling thus reducing its own grant. In embodiments, offlinecontrol can increase the grant to online control; online control candecrease its own grant. In embodiments, the ‘Print Limiter’ smartcontract may include instructions requiring authorization of multiplekeys to increase the supply of Stable Value Tokens. In embodiments, themultiple keys may require at least two signers. This could include usinga M of N model, where M is at least 2 and N is equal to or greater thanM (e.g., 2 or more, when M is 2). Thus, in embodiments, multiple keysmay include a set number of keys of a set number of possible keys, forexample, two keys of a possible three keys. In embodiments, the multiplekeys may require all keys of possible keys, for example, three keys of apossible three keys. In embodiments, the arrangement discussed hereinachieves a hybrid of online and offline control over the supply ofStable Value Tokens. In embodiments, tokens can be issued in anefficient and timely manner, while the risk of inflation of the supplyof Stable Value Tokens without backing U.S. Dollars is bounded.

In embodiments, as noted above, multiple signatures may be required forcertain transactions such as those requiring intervention of theCustodian 1350. In embodiments, as noted above, changing theimplementation pointer from ERC20Proxy 1310 which is currently set atS1312 (impl) to point to ERC20Impl 1320 (Version 1), requires resettingS1312B “impl” to point to ERC20Impl 1320A (version 2). In embodiments, arequest is made to ERC20Proxy to change its instance of ERC20Impl. Whenthe request is made, a unique lockId is generated. In embodiments, theCustodian contract 1350 for ERC20 Proxy 1310 calls requestUnlock andpasses as arguments the lockId generated for the change request, and thefunction in ERC20Proxy 1310 the Custodian 1350 needs to call to confirmthe change request. This generates a request, which is a uniqueidentifier for this unlock request.

In embodiments, to complete the unlocking of Custodian and thereforepropagate the change to ERC20Proxy 1310, the digital asset systemoperated by the token issuer uses its off-line key storageinfrastructure to sign the request with the previously approveddesignated key sets. This may require the use of two or more key sets.

In embodiments, those signatures are passed into the Custodian'scompleteUnlock function along with the initial request. Once the requestis validated against the signatures, completeUnlock parses the contentof the request and issues the command. In this exemplary case,ERC20Proxy's confirmImplChange is called using the lockId generated inthe initial ERC20Impl change request.

In embodiments, the arrangement discussed herein achieves a hybrid ofonline and offline control over the supply of Stable Value Tokens. Inembodiments, tokens can be issued in an efficient and timely manner,while the risk of inflation of the supply of Stable Value Tokens withoutthe backing of U.S. Dollars is bounded. In embodiments, pending actionsmay be revoked, allowing for the nullification of erroneous or maliciousactions before being executed.

A method of withdrawing stable value digital asset tokens based on anunderlying digital asset from a digital asset exchange computer systemin exchange for fiat, in accordance with an embodiment of the presentapplication includes: (a) authenticating, by the digital asset exchangecomputer system associated with a digital asset exchange, an accessrequest by a first user device associated with a first user, to thedigital asset exchange computer system comprising the steps of: (1)receiving, by the digital asset exchange computer system from the firstuser device, an authentication request including first user credentialinformation associated with the first user; (2) determining, by thedigital asset exchange computer system, that the first user device isauthorized to access the digital asset exchange computer system based atleast in part on the first user credential information; (3) generating,by the digital asset exchange computer system, first graphical userinterface information for displaying a first graphical user interface onthe first user device; (4) transmitting, from the digital asset exchangecomputer system to the first user device, the first graphical userinterface information; (b) obtaining, by the digital asset computersystem from the first user device, a withdraw request comprising thesteps of: (1) receiving, by the digital asset exchange computer systemfrom the first user device, a first electronic request to withdrawstable value digital asset tokens, wherein the stable value digitalasset token is tied to an underlying digital asset which is maintainedon a distributed public transaction ledger in the form of a blockchainthat is maintained by a blockchain network including a plurality ofgeographically distributed computer systems in a peer-to-peer network;(2) in response to the first electronic request, obtaining, by thedigital asset exchange computer system from a fiat account ledgerdatabase stored on computer readable member accessible by the digitalasset exchange computer system, first account balance information of thefirst user indicating a first amount of available fiat for the firstuser held by the digital asset exchange on behalf of the first user; (3)generating, by the digital asset exchange computer system, secondgraphical user interface information including at least the firstaccount balance information; (4) transmitting, by the digital assetexchange computer system to the first user device, the second graphicaluser interface information; (5) receiving, by the digital asset exchangecomputer system from the first user device, a second electronicwithdrawal request comprising at least: (A) a first amount of stablevalue digital asset tokens to be withdrawn; and (B) a destination publicaddress on the underlying blockchain to transfer the first amount ofstable value digital asset tokens; (c) processing, by the digital assetexchange computer system, the withdraw request by the steps of: (1)calculating, by the digital asset exchange computer system, a secondamount of fiat based on the first amount of stable value digital assettokens, where the second amount of fiat is determined using a fixedpredetermined ratio of stable value digital asset tokens to fiat; (2)determining, by the digital asset exchange computer system, that thesecond amount of fiat is less than the first amount of available fiat ofthe first user; (3) in the case where the second amount of fiat is lessthan the first amount of available fiat of the first user, determining athird amount of fiat associated with an updated amount of available fiatof the first user, wherein the third amount of fiat equals the firstamount of available fiat of the first user less the second amount offiat; (4) updating, by the digital asset exchange computer system, thefiat account ledger database to reflect that the updated amount ofavailable fiat of the first user is the third amount of fiat; (5)updating, by the digital asset exchange computer system, a stable valuedigital asset token issuer fiat ledger, to increase a balance of fiat bythe second amount of fiat; (6) generating, by the digital asset exchangecomputer system, a first transaction request for the blockchain, from afirst digital asset exchange public key address on the blockchain, whichis mathematically related to a first digital asset exchange private key,which is stored in the computer readable member accessible by thedigital asset exchange computer system, to a first contract addressassociated with a stable value token issuer, a first message including:i. a request to obtain in the first designated public address of thefirst user the first amount of stable value digital asset tokens; andwherein the first transaction request is signed with a digital signaturegenerated using the digital asset exchange private key; (7)transmitting, by the digital asset exchange computer system to theblockchain network via the Internet, the first transaction request; (8)confirming, by the digital asset exchange computer system by referenceto the blockchain, that the balance of stable value digital asset tokensin the first designated public address of the first user includes thefirst amount of stable value digital asset tokens.

In embodiments, the determining step (a) (c) further determines that thefirst user is a registered user of the digital asset exchange.

In embodiments, the digital asset exchange is licensed by a governmentregulatory authority.

In embodiments, the underlying digital asset is ether and the blockchainis the Ethereum Blockchain.

In embodiments, the underlying digital asset is neo and the blockchainis the Neo Blockchain.

In embodiments, the fixed predetermined ratio is one stable valuedigital asset token is equal to one U.S. dollar.

In embodiments, the fixed predetermined ratio is one hundred stablevalue digital asset tokens is equal to one U.S. dollar.

In embodiments, the updating step (c) (5) further comprises transferringthe second amount of fiat from a digital asset exchange fiat account toa stable value digital asset token issuer fiat account.

In embodiments, the updating step (c) (5) further comprises periodicallytransferring fiat between the digital asset exchange fiat account andthe stable value digital asset token issuer fiat account.

In embodiments, the instructions to obtain in the first designatedpublic address of the first user the first amount of stable valuedigital asset tokens include instructions to generate the first amountof stable value digital asset tokens at the first designated publicaddress of the first user.

In embodiments, the instructions to obtain in the first designatedpublic address of the first user the first amount of stable valuedigital asset tokens include instructions to transfer the first amountof stable value digital asset tokens from a stable value digital assettoken issuer public address to the first designated public address ofthe first user.

A method of depositing stable value digital asset tokens based on anunderlying digital asset into a digital asset exchange computer systemin exchange for fiat in accordance with another embodiment of thepresent application includes: (a) authenticating, by the digital assetexchange computer system associated with a digital asset exchange, anaccess request by a first user device associated with a first user, tothe digital asset exchange computer system comprising the steps of: (1)receiving, by the digital asset exchange computer system from the firstuser device, an authentication request including first user credentialinformation associated with the first user; (2) determining, by thedigital asset exchange computer system, that the first user device isauthorized to access the digital asset exchange computer system based atleast in part on the first user credential information; (3) generating,by the digital asset exchange computer system, first graphical userinterface information for displaying a first graphical user interface onthe first user device; (4) transmitting, from the digital asset exchangecomputer system to the first user device, the first graphical userinterface information; (b) obtaining, by the digital asset computersystem from the first user device, a deposit request comprising thesteps of: (1) receiving, by the digital asset exchange computer systemfrom the first user device, a first electronic request to deposit stablevalue digital asset tokens, wherein the stable value digital asset tokenis tied to an underlying digital asset which is maintained on adistributed public transaction ledger in the form of a blockchain thatis maintained by a blockchain network including a plurality ofgeographically distributed computer systems in a peer-to-peer network;(2) in response to the first electronic request, obtaining, by thedigital asset exchange computer system from a fiat account ledgerdatabase stored on computer readable member accessible by the digitalasset exchange computer system, first account balance information of thefirst user indicating a first amount of available fiat for the firstuser held by the digital asset exchange on behalf of the first user; (3)obtaining, by the digital asset exchange computer system, a userspecific destination address, uniquely associated with the first user;(4) generating, by the digital asset exchange computer system, secondgraphical user interface information including at least the firstaccount balance information and the user specific destination address;(5) transmitting, by the digital asset exchange computer system to thefirst user device, the second graphical user interface information; (6)receiving, by the digital asset exchange computer system from the firstuser device, a second electronic deposit request comprising at least:(A) a first amount of stable value digital asset tokens to be deposited;and (B) a designated public address of the first user on the underlyingblockchain from which the first amount of stable value digital assettokens will be transferred; (C) a digital signature based on adesignated private key of the first user, wherein the designated privatekey is mathematically related to the designated public address; (c)processing, by the digital asset exchange computer system, the secondelectronic deposit request by the steps of: (1) calculating, by thedigital asset exchange computer system, a second amount of fiat based onthe first amount of stable value digital asset tokens, where the secondamount of fiat is determined using a fixed predetermined ratio of stablevalue digital asset tokens to fiat; (2) determining, by the digitalasset exchange computer system, that the first amount of stable valuedigital asset tokens is present at the designated public address of thefirst user; (3) in the case where the first amount of stable valuedigital asset tokens is present at the designated public address of thefirst user, determining a third amount of fiat associated with anupdated amount of available fiat of the first user, wherein the thirdamount of fiat equals the first amount of available fiat of the firstuser plus the second amount of fiat; (4) updating, by the digital assetexchange computer system, the fiat account ledger database to reflectthat the updated amount of available fiat of the first user is the thirdamount of fiat; (5) generating, by the digital asset exchange computersystem, a first transaction request for the blockchain, from a firstdigital asset exchange public key address on the blockchain, which ismathematically related to a first digital asset exchange private key,which is stored in the computer readable member accessible by thedigital asset exchange computer system, to a first contract addressassociated with a stable value token issuer, a first message including:i. a request to obtain, from the first designated public address of thefirst user, the first amount of stable value digital asset tokens fromthe designated public address of the first user and provide the firstamount of stable value digital asset tokens to the user specificdestination address; and ii. a request to destroy the first amount ofstable value digital asset tokens; wherein the first transaction requestis signed with a digital signature generated based on the digital assetexchange private key of the user digital asset exchange; (6) updating,by the digital asset exchange computer system, a stable value digitalasset token issuer fiat ledger, to decrease a balance of fiat by thesecond amount of fiat; (7) transmitting, by the digital asset exchangecomputer system to the blockchain network via the Internet, the firsttransaction request; (8) confirming, by the digital asset exchangecomputer system by reference to the blockchain, that the first amount ofstable value digital asset tokens are not present at the designatedpublic address of the first user.

In embodiments, the determining step (a) (2) further determines that thefirst user is a registered user of the digital asset exchange.

In embodiments, the digital asset exchange is licensed by a governmentregulatory authority.

In embodiments, the underlying digital asset is ether and the blockchainis the Ethereum Blockchain.

In embodiments, the underlying digital asset is neo and the blockchainis the Neo Blockchain.

In embodiments, the fixed predetermined ratio is one stable valuedigital asset token is equal to one U.S. dollar.

In embodiments, the fixed predetermined ratio is one hundred stablevalue digital asset tokens is equal to one U.S. dollar.

In embodiments, the updating step (c) (6) further comprises transferringthe second amount of fiat from a digital asset exchange fiat account toa stable value digital asset token issuer fiat account.

In embodiments, the updating step (c) (6) further comprises periodicallytransferring fiat between the digital asset exchange fiat account andthe stable value digital asset token issuer fiat account.

A method of depositing stable value digital asset tokens based on anunderlying digital asset into a digital asset exchange computer systemin exchange for fiat in accordance with an embodiment of the presentapplication includes: (a) authenticating, by the digital asset exchangecomputer system associated with a digital asset exchange, an accessrequest by a first user device associated with a first user, to thedigital asset exchange computer system comprising the steps of: (1)receiving, by the digital asset exchange computer system from the firstuser device, an authentication request including first user credentialinformation associated with the first user; (2) determining, by thedigital asset exchange computer system, that the first user device isauthorized to access the digital asset exchange computer system based atleast in part on the first user credential information; (3) generating,by the digital asset exchange computer system, first graphical userinterface information for displaying a first graphical user interface onthe first user device; (4) transmitting, from the digital asset exchangecomputer system to the first user device, the first graphical userinterface information; (b) obtaining, by the digital asset computersystem from the first user device, a deposit request comprising thesteps of: (1) receiving, by the digital asset exchange computer systemfrom the first user device, a first electronic request to deposit stablevalue digital asset tokens, wherein the stable value digital asset tokenis tied to an underlying digital asset which is maintained on adistributed public transaction ledger in the form of a blockchain thatis maintained by a blockchain network including a plurality ofgeographically distributed computer systems in a peer-to-peer network;(2) in response to the first electronic request, obtaining, by thedigital asset exchange computer system from a fiat account ledgerdatabase stored on computer readable member accessible by the digitalasset exchange computer system, first account balance information of thefirst user indicating a first amount of available fiat for the firstuser held by the digital asset exchange on behalf of the first user; (3)obtaining, by the digital asset exchange computer system, a userspecific destination address, uniquely associated with the first user;(4) generating, by the digital asset exchange computer system, secondgraphical user interface information including at least the firstaccount balance information and the user specific destination address;(5) transmitting, by the digital asset exchange computer system to thefirst user device, the second graphical user interface information; (6)receiving, by the digital asset exchange computer system from the firstuser device, a second electronic deposit request comprising at least:(A) a first amount of stable value digital asset tokens to be deposited;and (B) a designated public address of the first user on the underlyingblockchain from which the first amount of stable value digital assettokens will be transferred; (C) a digital signature based on adesignated private key of the first user, wherein the designated privatekey is mathematically related to the designated public address; (c)processing, by the digital asset exchange computer system, the secondelectronic deposit request by the steps of: (1) calculating, by thedigital asset exchange computer system, a second amount of fiat based onthe first amount of stable value digital asset tokens, where the secondamount of fiat is determined using a fixed predetermined ratio of stablevalue digital asset tokens to fiat; (2) determining, by the digitalasset exchange computer system, that the first amount of stable valuedigital asset tokens is present at the designated public address of thefirst user; (3) in the case where the first amount of stable valuedigital asset tokens is present at the designated public address of thefirst user, determining a third amount of fiat associated with anupdated amount of available fiat of the first user, wherein the thirdamount of fiat equals the first amount of available fiat of the firstuser plus the second amount of fiat; (4) updating, by the digital assetexchange computer system, the fiat account ledger database to reflectthat the updated amount of available fiat of the first user is the thirdamount of fiat; (5) generating, by the digital asset exchange computersystem, a first transaction request for the blockchain, from a firstdigital asset exchange public key address on the blockchain, which ismathematically related to a first digital asset exchange private key,which is stored in the computer readable member accessible by thedigital asset exchange computer system, to a first contract addressassociated with a stable value token issuer, a first message including:i. a request to obtain from the first designated public address of thefirst user the first amount of stable value digital asset tokens fromthe designated public address of the first user and provide them to theuser specific destination address; ii. a request to store the firstamount of stable value digital asset tokens at the user specificdestination address; and wherein the first transaction request is signedwith a digital signature generated based on the digital asset exchangeprivate key of the user digital asset exchange; (6) transmitting, by thedigital asset exchange computer system to the blockchain network via theInternet, the first transaction request; (7) confirming, by the digitalasset exchange computer system by reference to the blockchain, that thefirst amount of stable value digital asset tokens are not present at thedesignated public address of the first user.

In embodiments, the determining step (a) (2) further determines that thefirst user is a registered user of the digital asset exchange.

In embodiments, the digital asset exchange is licensed by a governmentregulatory authority.

In embodiments, the underlying digital asset is ether and the blockchainis the Ethereum Blockchain.

In embodiments, the underlying digital asset is neo and the blockchainis the Neo Blockchain.

In embodiments, the fixed predetermined ratio is one stable valuedigital asset token is equal to one U.S. dollar.

In embodiments, the fixed predetermined ratio is one hundred stablevalue digital asset tokens is equal to one U.S. dollar.

Increasing the Total Supply of Digital Asset Tokens

FIG. 18A is a schematic drawing of an exemplary system for increasingthe total supply of digital asset tokens on an underlying blockchain inaccordance with exemplary embodiments of the present invention. Thesystem shown in FIG. 18A may include an administrator system 1801 whichmay communicate with a plurality of end users, each of which may accessthe network 15 using one or more corresponding user device 1805, . . .1805X, a blockchain 1807, and one or more on-line keysets 1362, . . .1362N.

In embodiments, network 15, may be a wide area network, a local areanetwork, a telephone network, dedicated access lines, a proprietarynetwork, a satellite network, a wireless network, a mesh network, orthrough some other form of end-user to end-user interconnection, whichmay transmit data and/or other information. Any participants in adigital asset network may be connected directly or indirectly, asthrough the data network 15, through wired, wireless, or otherconnections. In embodiments, network 15 may be accessed using TransferControl Protocol and Internet Protocol (“TCP/IP”) (e.g., any of theprotocols used in each of the TCP/IP layers), Hypertext TransferProtocol (“HTTP”), WebRTC, SIP, and wireless application protocol(“WAP”), are some of the various types of protocols that may be used tofacilitate communications between administrator system 1801 and userdevices 1805, . . . 1805X. In some embodiments, el administrator system1801 and/or user devices 1805, . . . 1805X may communicate with oneanother via a web browser using HTTP. Various additional communicationprotocols may be used to facilitate communications between administratorsystem 1801 and/or user devices 1805, . . . 1805X, including, but notlimited to, Wi-Fi (e.g., 802.11 protocol), Bluetooth, radio frequencysystems (e.g., 900 MHz, 1.4 GHz, and 5.6 GHz communication systems),cellular networks (e.g., GSM, AMPS, GPRS, CDMA, EV-DO, EDGE, 3GSM, DECT,IS 136/TDMA, iDen, LTE or any other suitable cellular network protocol),infrared, BitTorrent, FTP, RTP, RTSP, SSH, and/or VOIP.

As illustrated in FIG. 18A, the administrator system 1801 and/or userdevices 1805, . . . 1805X may communicate with a blockchain network toaccess and/or add blocks to blockchain 1807. User devices 1805, . . .1805X may for instance, may correspond to a suitable electronic device,such as, desktop computers, mobile computers (e.g., laptops,ultrabooks), mobile phones, smart phones, tablets, personal displaydevices, large scale display devices (e.g., billboards, street signs,etc.), personal digital assistants (“PDAs”), gaming consoles and/ordevices, smart vehicles (e.g., cars, trucks, motorcycles, etc.), smarttransportation devices (e.g., boats, ships, trains, airplanes, etc.),and/or wearable devices (e.g., watches, pins/broaches, headphones,etc.), to name a few.

The blockchain 1807 may include one more contract addresses, such ascontract address for, e.g., a proxy smart contract 1310 (contractaddress 1), IMPL smart contract 1320 (contract address 2), PRINT LIMITERsmart contract 1360 (contract address 3), STORE smart contract 1330(contract address 4), CUSTODIAN 1 smart contract 1819 (contract address5), CUSTODIAN 2 smart contract 1350 (contract address 6), CUSTODIAN 3smart contract 1823 (contract address 7), as illustrated in FIG. 18A.Each contract address may include one or more contract addresses.Additionally, in embodiments, one or more contract addresses shown inconnection with FIG. 18A may be associated with one or more contractaddresses. For example, in embodiments, contract address 1 may be thesame contract address as contract address 2. The blockchain 1807 mayalso include public addresses, such as off-line public address 1 1817,off-line public address N 1817N, on-line public address 1 1825, on-linepublic address N 1825N, user 1 public address 1827, and User X publicaddress 1827X, as illustrated in FIG. 18A.

In embodiments, the blockchain 1807 may be a plurality of geographicallydistributed computer systems in a peer-to-peer network. Wirelesscommunication may be provided using any of a variety of communicationprotocols and/or wireless communication networks, including e.g. GSM,GSM-R, UMTS, TD-LTE, LTE, LTE-Advanced Pro, LTE Advanced, Gigabit LTE,CDMA, iDEN, MVNO, MVNE, Satellite, TETRA, WiMAX, AMPS TDMA, Roaming SIM,DC-HSPA, HSPA, HSPA+, HSDPA, G, 2G, 3.5G, 4G, 4.5G, 5G, 5.5G, 6G, 6.5G,VoLTE, EDGE, GPRS, GNSS, EV-DO, 1xRTT, WCDMA, TDS-CDMA, CDMA2000, CSFB,FDMA, OFDMA, PDMA, AMPS, EV-DO, DECT, IS-95, NMT, UMTS, MPLS, MOCA,Broadband over Power Lines, NB-IoT, enhanced MTC (eMTC), LTE-WLAN, ISDN,Microwave, Long Range Wifi, Point to Point Wifi, EC-GSM-IoT, LTE-M,NB-IoT, Evolved Multicast Broadcast Multimedia Service (eMBMS) andLTE-Broadcast (LTE-B), to name a few.

The system described in connection with FIG. 18A may include one or moreon-line keysets 1362, . . . 1362N. Each keyset includes a private keyand a corresponding public key (or public address on the blockchain).For example, on-line keyset 1362 may be associated with on-line publicaddress 1 1825. Similarly, by way of example, on-line keyset N 1362N maybe associated with on-line public address N 1825N. In embodiments, eachprivate key will typically be mathematically related to thecorresponding public key, such as used with cryptocurrency SecurityStandard. In embodiments, the one or more on-line keysets 1362, . . .1362N may be stored on non-volatile computer readable memory of one ormore computer systems that are connected to the network, such as a firstcomputer system.

The system described in connection with FIG. 18A may also include one ormore off-line keyset 1803, . . . 1803N. Each keyset includes a privatekey and a corresponding public key (or public address on theblockchain). The offline keyset 1803 may be stored in on non-volatilecomputer readable memory of one or more computer systems that arephysically separated from network 15, blockchain 1807, administratorsystem 1801, and the one or more computer systems that store the on-linekeysets, such as a second computer system. In embodiments, the secondcomputer system that is physically separated and/or electronically maybe a hardware storage module (HSM 1900—as described more fully inconnection with FIG. 19B). The physical and/or electronic separation mayserve as an additional security measure(s), protecting the one or moreoff-line keyset 1803, . . . 1803N from unauthorized access. Inembodiments, the one or more off-line keyset 1803, . . . 1803N may beassociated with address on the blockchain 1807. In embodiments, off-linekeyset 1 1803 may be associated with off-line public address 1 1817.Off-line keyset 1803N may be associated with off-line public address N1817.

In embodiments, proxy smart contract 1310 may have a contract address(e.g., contract address 1) associated therewith on the blockchain1807proxy smart contract 1310. Proxy smart contract 1310, as seen inFIG. 18B, by way of illustration and as discussed in greater detail withrespect to FIGS. 20A-20A-1, 20B-20C and 21A-21B, may include one or moremodules of instructions 1310A-1 such as: (1) PROXY delegationinstructions module 1829 (i.e. first delegation instructions module) and(2) PROXY authorization instructions module 1831 (i.e. firstauthorization instructions module), to name a few.

In embodiments, PROXY delegation instructions module 1829 (i.e. firstdelegation instructions module) may include one or more instructions todelegate received requests to other smart contracts on the blockchain,such as, for example, IMPL smart contract 1320 (contract address 2),PRINT LIMITER smart contract 1360 (contract address 3), STORE smartcontract 1330 (contract address 4), CUSTODIAN 1 smart contract 1819(contract address 5), CUSTODIAN 2 smart contract 1350 (contract address6), CUSTODIAN 3 smart contract 1823 (contract address 7), to name a few.Additionally, in embodiments, PROXY delegation instructions module 1829(i.e. first delegation instructions module) may include one or moreinstructions to delegate received requests to public addresses such asoff-line public address 1 1817, off-line public address N 1817N, on-linepublic address 1 1825, on-line public address N 1825N, user 1 publicaddress 1827, and/or User X public address 1827X, to name a few.

In embodiments, the first authorization instruction module 1831 mayinclude instructions to authorize request received, the requests, inembodiments, being transaction requests from administrators, user publicaddresses, or other smart contracts, to name a few.

In embodiments, PRINT LIMITER smart contract 1360 may have a contractaddress (e.g. contract address 3) associated therewith on the blockchain1807. PRINT LIMITER smart contract 1360, as seen in FIG. 18C, by way ofillustration and as discussed in greater detail with respect to FIGS. 20and 21, may include one or more modules of instructions 1360A-1 such as:(1) PRINT LIMITER token creation instructions module 1833, (2), PRINTLIMITER first authorization instructions module 1839 (i.e. secondauthorization instructions module), (3) PRINT LIMITER secondauthorization instructions module 1841 (i.e. third authorizationinstructions module), (4) token transfer instructions module 1843, (5)token destruction instructions module 1845, and (6) token balancemodification instructions module 1847.

In embodiments, PRINT LIMITER token creation instructions module 1833may include one or more instructions that indicate conditions underwhich tokens of a digital asset token are created. In embodiments, thePRINT LIMITER token creation instructions module 1833 may includeinstructions that limit the conditions under which tokens may becreated. For example, the PRINT LIMITER token creation instructionsmodule 1833 may include instructions that limit the production of tokensto 1,000,000 tokens. In embodiments, the instructions may also include atemporal component. For example, the PRINT LIMITER token creationinstructions module 1833 may include instructions that only allow 1,000tokens to be created within a 24 hour period. Or, as another example,the PRINT LIMITER token creation instructions module 1833 may includeinstructions that only allow tokens to be created during business hours.In embodiments, the PRINT LIMITER may also include authorizationinstructions related to the first key pair.

In embodiments, custodian instructions module 1835 may include one ormore instructions that limit the PRINT LIMITER smart contract 1360Aauthority. For example, if a request is received by the PRINT LIMITERsmart contract 1360 to create digital asset tokens beyond a pre-approvedtoken supply limit, the custodian instructions module 1835 may requireauthorization from a print limiter custodian (i.e. CUSTODIAN 2 smartcontract 1350 (contract address 6)).

In embodiments, the second authorization instruction module 1839 and thePRINT LIMITER second authorization instructions module 1841 (i.e. thirdauthorization instructions module) may each include instructions toauthorize request received, the requests, in embodiments, beingtransaction requests from administrators, user public addresses, orother smart contracts, to name a few. Second authorization instructionmodule 1839 may include instructions for the first designated key pair(on-line keyset 1 1362, . . . 1362N), with respect to token creation ofthe digital asset token. In embodiments, the second authorizationinstructions with respect to token creation may be below a firstthreshold over a first period of time. PRINT LIMITER secondauthorization instructions module 1841 (i.e. third authorizationinstructions module) may include instructions for the second designatedkey pair (i.e. off-line keyset 1803, . . . 1803N) with respect to tokencreation of the digital asset token. In embodiments, PRINT LIMITER firstauthorization instructions module 1839 and PRINT LIMITER secondauthorization instructions module 1841 may be the same module.

In embodiments, the PRINT LIMITER Third Authorization InstructionsModule 1835 may include instructions to modify the token supply. Forexample, the PRINT LIMITER Third Authorization Instructions Module 1835may include instructions that, when called to execute, may create and/orburn tokens of the digital asset token. In embodiments, instructionsthat modify the token supply may cause the STORE Smart Contract 1330 toalter an electronic ledger that tracks the token supply.

In embodiments, the token transfer instructions module 1843, inembodiments, may include instructions to transfer digital asset tokens.In embodiments, the transfer may be from one public address to anotherpublic address. For example, a transfer of tokens may be from User 1public address 1827 to User X public address 1827X. In embodiments, suchtransfer instructions may include rules by which certain transfer areallowed or blocked and may specify one or more key pair or contractaddresses that may be authorized to perform one or more types oftransfer operations. A more detailed description of the transfer ofdigital asset tokens is located in connection with the description ofFIG. 19D, the same description applying herein.

In embodiments, the token destruction instructions module 1845 mayinclude instructions on when, and with whose authority, security tokensassociated with one or more specified addresses shall be destroyed or“burned”, and thus removed from the security token supply. A moredetailed description of token destruction is described in connectionwith FIG. 19E, the same description applying herein

In embodiments, token balance modification instructions module 1847 mayinclude instructions that may alter, edit, and/or update a transactionledger in accordance with token creation, token transfer, and/or tokendestruction instructions (or modules), to name a few.

In embodiments, CUSTODIAN 2 smart contract may have a contract address(e.g. contract address 6) associated therewith on the blockchain 1807.CUSTODIAN 2 smart contract 1350, as seen in FIG. 18D, by way ofillustration and as discussed in greater detail with respect to FIGS. 20and 21, may include one or more modules of instructions 1350A-1 such as:(1) CUSTODIAN 2 first authorization instructions module 1849 (i.e.fourth authorization instructions module) and (2) CUSTODIAN 2 secondauthorization instructions module 1851 (i.e. fifth authorizationinstructions module). In embodiments, CUSTODIAN 2 first authorizationinstructions module 1849 and CUSTODIAN 2 second authorizationinstructions module 1851 may be the same module.

In embodiments, the CUSTODIAN 2 first authorization instructions module1849 (i.e. fourth authorization instructions module) and the CUSTODIAN 2second authorization instructions module 1851 (i.e. fifth authorizationinstructions module) may each include instructions to authorize requestreceived, the requests, in embodiments, being transaction requests fromadministrators, user public addresses, or other smart contracts, to namea few CUSTODIAN 2 first authorization instructions module 1849 (i.e.fourth authorization instructions module) may include instructions forthe off-line keyset 1803, . . . 1803N to authorize the issuance ofinstructions to the PRINT LIMITER smart contract 1360 with respect totoken creation, above a first threshold during a first period of time.CUSTODIAN 2 second authorization instructions module 1851 (i.e. fifthauthorization instructions module) may include instructions to raise aceiling of token creation. A more detailed description of raising theceiling of token creation is located below in the descriptions inconnection with FIGS. 19A-B and 20A.

In embodiments, STORE smart contract 1330 may have a contract address(e.g. contract address 4) associated therewith on the blockchain 1807.STORE smart contract 1330, as seen in FIG. 18E, by way of illustrationas discussed in greater detail with respect to FIGS. 20 and 21, mayinclude one or more modules of instructions 1330A-1 such as: (1) storageinstructions module 1853 and (2) STORE authorization instructions module1855 (i.e. sixth authorization instructions module).

In embodiments, storage instructions module 1853, may includeinstructions to store any alterations, edits, or updates to atransaction ledger in accordance with token creation, token transfer,and/or token destruction. In embodiments, the storage instructionsmodule 1853 may be called through a transaction request received fromone or more smart contracts. For example, as shown in FIG. 19C, the IMPLsmart contract 1320 may call the store smart contract 1330, authorizingthe change of a transaction ledger to include an earlier transaction. Inembodiments, the transaction ledger may be updated immediately aftereach token creation, transfer, and/or destruction. In embodiments, thestorage instructions module 1853 may execute instructions to update atransaction ledger at certain times and/or dates. For example, thestorage instructions module 1853 may only update a transaction ledger atthe close of business. As another example, the storage instructionsmodule 1853 may only update a transaction ledger at every second,minute, hour, or multiple hours, to name a few. A more detaileddescription of instructions related to the storage instructions module1853 is located in connection with the descriptions of FIGS. 19-21, thesame descriptions applying herein.

In embodiments, the STORE authorization instructions module 1855 mayinclude instructions to authorize request received, the requests, inembodiments, being transaction requests from administrators, user publicaddresses, or other smart contracts, to name a few.

In embodiments, IMPL smart contract 1320 may have a contract address(e.g. contract address 2) associated therewith on the blockchain 1807.The IMPL smart contract 1320, as seen in FIG. 18F, by way ofillustration and discussed in greater detail with respect to FIGS.19-21, may include one or more modules of instructions 1320A-1 such as:(1) Generate Hash Instructions Module 1857; (2) IMPL AuthorizationInstructions Module 1859; (3) IMPL Token Transfer Instructions Module1861; (4) IMPL Token Balance Modification Instructions Module 1863; (5)IMPL delegation instructions module 1837 (i.e. second delegationinstructions module); and (6) IMPL Token Creation Instructions Module1865.

In embodiments, the generate hash instructions module 1857 may includeinstructions to generate a unique hash. A unique hash may be generatedby the generate hash instructions module 1857 by applying a hashalgorithm. Examples of hash algorithms include MD 5, SHA 1, SHA 256,RIPEMD, and Keccak-256, to name a few. Hash algorithms take an input ofany length and create an output of fixed length, allowing the tradeinstructions to be detectable and usable by administrators and users onthe underlying blockchain.

In embodiments, the IMPL authorization instructions module 1859 mayinclude instructions to authorize request received, the requests, inembodiments, being transaction requests from administrators, user publicaddresses, or other smart contracts, to name a few. In embodiments, therequests may include requests to generate digital asset tokens fromadministrators, user public addresses, and/or other smart contracts, toname a few.

In embodiments, the IMPL token transfer instructions module 1861 mayinclude instructions to transfer digital asset tokens. In embodiments,the transfer may be from one public address to another public address.For example, a transfer of tokens may be from User 1 public address 1827to User X public address 1827X. In embodiments, such transferinstructions may include rules by which certain transfer are allowed orblocked and may specify one or more key pair or contract addresses thatmay be authorized to perform one or more types of transfer operations.In embodiments, the IMPL token transfer instructions module 1861 may besimilar to the token transfer instructions module 1843, described inconnection with FIG. 18C. In embodiments, a transfer of digital assettokens using the blockchain 1807 may be accomplished using either theIMPL token transfer instructions module 1861 or the token transferinstructions module 1843. In embodiments, a transfer of digital assettokens using the blockchain 1807 may be accomplished using both the IMPLtoken transfer instructions module 1861 and the token transferinstructions module 1843. In embodiments, the IMPL smart contract 1320and the PRINT LIMITER smart contract 1360 may be the same smartcontract. A more detailed description of the transfer of digital assettokens is located in connection with the description of FIG. 19D, thesame description applying herein.

In embodiments, IMPL token balance modification instructions module 1863may include instructions that may alter, edit, and/or update atransaction ledger in accordance with token creation, token transfer,and/or token destruction instructions (or modules), to name a few. Inembodiments, the IMPL token balance modification instructions module1863 may be similar to the token balance modification module 1847described in connection with FIG. 18C. In embodiments, a token balancemodification may be accomplished using either the token balancemodification module 1847 or the IMPL token balance modification module1863. In embodiments, a token balance modification may be accomplishedusing both the token balance modification module 1847 and the IMPL tokenbalance modification module 1863. A more detailed description of a tokenbalance modification is located in connection with the description ofFIGS. 19-21, the same descriptions applying herein.

In embodiments, IMPL delegation instructions module 1837 (i.e. seconddelegation instructions module) may include one or more instructions todelegate received requests to other smart contracts, such as, forexample, contract address 1 (proxy smart contract) 1809, PRINT LIMITERsmart contract 1360 (contract address 2), STORE smart contract 1330(contract address 4), CUSTODIAN 1 smart contract 1819 (contract address5), CUSTODIAN 2 smart contract 1350 (contract address 6), CUSTODIAN 3smart contract 1823 (contract address 7), off-line public address 11817, off-line public address N 1817N, on-line public address 1 1825,on-line public address N 1825N, user 1 public address 1827, and/or UserX public address 1827X. PRINT LIMITER delegation instructions module1837 (i.e. second delegation instructions module) may includeinstructions for delegating to one or more designated store contractaddresses data storage operations or other functions for the digitalasset token as authorized by the first designated custodian contractaddress.

In embodiments, the IMPL token creation module 1865 may include one ormore instructions to create digital asset tokens, and thus add to thetoken supply. Such instructions may specify one or more authorized keypairs or contract addresses that may be authorized to request creationof security tokens under specified conditions (such as one or moreon-line keysets 1362, . . . 1362N). In embodiments, the token creationinstructions module 1833 may include instructions related to increasingthe token supply. In embodiments, the token creation instructions module1865 may include instructions on how to create new digital asset tokenswithin pre-approved token supply limits and how to assign newly createdor “minted” tokens to specific designated public addresses or contractaddresses on the underlying blockchain. In embodiments, the IMPL tokencreation module 1865 may cause the IMPL Smart Contract 1320 tocommunicate with STORE Smart contract 1330, the IMPL Smart Contract 1320sending a transaction request to the Store Smart Contract 1330, causingthe Store Smart Contract 1330 to alter a ledger, or otherwise record anincrease or decrease in the token supply of a digital asset token.

Referring to FIG. 20A, In step S2002, a first designated key pair(on-line keyset 1 1362) including a first public key of an underlyingdigital asset and a corresponding first designated private key isprovided. In embodiments, the underlying digital asset is maintained ona distributed public transaction ledger maintained by a plurality ofgeographically distributed computer systems in a peer-to-peer network inthe form of the blockchain 1807. In embodiments, the first designatedprivate key is stored on a first computer system which is connected tothe distributed public transaction ledger 15). In embodiments, the firstdesignated key pair may be multiple on-line keys with multipleelectronic signatures.

In step S2004, a second designated key pair including a seconddesignated public key (off-line keyset 1803) of the underlying digitalasset and a corresponding second designated private key is provided. Inembodiments, the second designated private key is stored on a secondcomputer system which is physically separated from the first computersystem and is not operatively or physically connected to the distributedpublic transaction ledger or the internet (network 15). In embodiments,the second computer system may be the hardware storage module 1900. Inembodiments, the second designated key pair may be multiple on-line keyswith multiple electronic signatures.

In step S2006, first smart contract instructions for a digital assettoken associated with a first contract address associated with theblockchain associated with the underlying digital asset are provided. Inembodiments, the first contract address is contract address 1 (proxysmart contract) 1809 and first smart contract instructions of step S2006are the proxy contract instructions 1310A-1, both described inconnection with FIG. 18B. The first smart contract instructions may besaved in the blockchain 1807 and include first delegation instructionsand first authorization instructions. The first delegation instructionsmay delegate one or more first functions associated with the digitalasset token to one or more delegated contract addresses associated withthe underlying digital asset, the delegated contract addresses, inembodiments, being different than the first contract address. Inembodiments, the first delegation instructions may be located with firstdelegation instruction module 1829 described in connection with FIG.18B. In embodiments, the first smart contract instructions, may alsoinclude first authorization instructions for the second designated keypair. In embodiments, the first authorization instructions may belocated with first authorization instructions module 1830 described inconnection with FIG. 18B.

In step S2008, second smart contract instructions for the digital assettoken associated with a second contract address associated with theblockchain associated with the underlying digital asset may be provided.In embodiments, the second smart contract address is at contract address3 (print limiter smart contact) 1813 and the second smart contractinstructions are the print limiter contract instructions 1360A-1, bothdescribed in connection with FIG. 18C. In embodiments, the secondcontract address is different from the first contract address. Inembodiments, the second smart contract instructions may be saved in theblockchain 1807 and, as described in connection with the print limitercontract instructions 1360A-1 of FIG. 18C (the descriptions of whichapplying herein), include: (1) token creation instructions; (2)custodian instructions; (3) second delegation instructions; (4) secondauthorization instructions; and (5) third authorization instructions. Inembodiments, as described above in connection with print limitercontract instructions 1360A-1 of FIG. 18C (the description of whichapplying herein), the second smart contract instructions may alsoinclude: (6) token transfer instructions of token transfer instructionsmodule 1843 to transfer tokens of the digital asset token from a firstdesignated address to a second designated address.

In embodiments, as described above in connection with print limitercontract instructions 1360A-1 of FIG. 18C (the description of whichapplying herein), the second smart contract instructions may alsoinclude: (7) token destruction instructions of token destructioninstructions module 1845 to destroy one or more tokens of the digitalasset token. Token destruction instructions, in embodiments, may not belimited to print limiter contract instructions 1360A-1. In embodiments,additional smart contracts may also destroy tokens, such as IMPL smartcontract 1320 (contract address 2), CUSTODIAN 1 smart contract 1819(contract address 5), CUSTODIAN 2 smart contract 1350 (contract address6), and/or CUSTODIAN 3 smart contract 1823 (contract address 7), to namea few.

In embodiments, as described above in connection with print limitercontract instructions 1360A-1 of FIG. 18C (the description of whichapplying herein), the second smart contract instructions may alsoinclude: (8) token balance modification instructions of token balancemodification instructions module 1847 to modify a total number of tokensof the digital asset token assigned to a third designated address.

In step S2010, third smart contract instructions for the digital assettoken associated with a third contract address associated with theblockchain associated with the underlying digital asset are provided. Inembodiments, the third smart contract address is CUSTODIAN 2 smartcontract 1350 (contract address 6) and the second smart contractinstructions are the custodian 2 contract instructions 1350A-1, bothdescribed in connection with FIG. 18D. The third smart contractinstructions may be saved in the blockchain 1807 and, as described inconnection with the custodian 2 smart contract instructions 1350A-1 ofFIG. 18D (the descriptions of which applying herein), include: (1)fourth authorization instructions and (2) fifth authorizationinstructions. The fourth authorization instructions of CUSTODIAN 2 firstauthorization instructions module 1849 (i.e. fourth authorizationinstructions module) may include instructions for the second designatedkey pair to authorize the issuance of instructions to the second smartcontract instructions with respect to token creation. In embodiments,the authorization instructions with respect to token creation may beabove the first threshold during the first time period.

In embodiments, a token creation request may exceed a ceiling (i.e. arequest for 150 tokens when the ceiling is 100 tokens), CUSTODIAN 2smart contract 1350 may authorize an increase in the ceiling. Thisauthorization may be fifth authorization instructions of the CUSTODIAN 2second authorization instructions module 1851 (i.e. fifth authorizationinstructions module), and may include instructions for the seconddesignated key pair (off-line keyset 1803, . . . 1803N) to authorize theissuance of instructions to the first smart contract instructions tochange the one or more designated contract address from the secondcontract address to a different designated contract address. Inembodiments, a ceiling is raised by creating a second print limitersmart contract on the blockchain 1807 with a higher ceiling. Once thesecond print limiter smart contract is created, the request for tokencreation can be routed to the second print limiter smart contract.

A more detailed description of the process of raising the token creationceiling is located in connection with FIGS. 19A-B. FIGS. 19A-B areschematic drawings of an exemplary process for increasing the ceiling ofa print limiter in accordance with exemplary embodiments of the presentinvention. The exemplary process starts with administrator system 1801sending a first transaction request 1901 from on-line public address 11825 to PRINT LIMITER smart contract 1360 (contract address 3). Inembodiments, the transaction request 1901 includes a request to raisethe ceiling by amount 1. In embodiments, the first transaction request1901 is signed by on-line private key 1. In embodiments, on-line privatekey 1 is mathematically related to on-line public address 1 1825.

In response to receiving the first transaction request, the printlimiter 1813 executes the first transaction request 1903 and returns aunique lock identifier (LockId1) to IMPL smart contract 1320 (contractaddress 2).

Next, referring to FIG. 19B, a second transaction request 1905 may besent from the on-line public address 1825 to contract address 6(custodian (print limiter)) 1821. In embodiments, the second transactionrequest 1905 includes a request to unlock ceiling raise by amount 1, therequest being confirmed with the lockID received in step 1903. Inembodiments, the second transaction request 1905 is signed by on-lineprivate key 1.

In response to receiving the second transaction request, custodian 1821executes the second transaction request 1907 and returns a unique hash(reqMessageHash1). The unique hash may be generated by applying a hashalgorithm. Examples of hash algorithms include MD 5, SHA 1, SHA 256,RIPEMD, and Keccak-256 to name a few. Hash algorithms take an input ofany length and create an output of fixed length, allowing the tradeinstructions to be detectable and usable by administrators and users onthe underlying blockchain. However, applying a hash algorithm is notalways necessary if trade instructions are published ahead of time.

In response to the returned unique hash, a third transaction request isgenerated 1909. The third transaction request may include a request thatthe reqMessageHash1 to be signed by HSM 1900 offline.

The third request then may be sent 1911 to HSM 1900 and signed usingoffline private keyset 1803. The signed request may be returned toadministrator system 1801.

After returning the signed transaction request, the third transactionrequest is may be sent 1913 from the on-line public address 1825 tocontract address 6 (custodian (print limiter)) 1821. The thirdtransaction request may include a fourth request to complete the unlockwith requestMessageHash1 with the HSM signature. In embodiments, thefourth request is signed by on-line private key 1.

After receiving the fourth request, custodian 1821 may execute therequest to validate the unlock and return call to contract address 3(print limiter) 1813 to raise the ceiling, which returns call tocontract address 4 (store) 1815 to raise ceiling which updates ceiling.

The process of FIG. 20A may continue with step S2012 of FIG. 20A-1. Instep S2012, fourth smart contract instructions for the digital assettoken associated with a fourth contract address associated with theblockchain associated with the underlying digital asset are provided. Inembodiments, the fourth contract address is STORE smart contract 1330(contract address 4) and fourth smart contract instructions of stepS2012 are the store contract instructions 1330A-1, both described inconnection with FIG. 18E. The fourth smart contract instructions mayinclude: (1) storage instructions and (2) sixth authorizationinstructions. In embodiments, storage instructions of storageinstructions module 1853 may include instructions for transaction datarelated to the digital asset token to be stored. The transaction datamay include (for all issued tokens of the digital asset token): (1)public address information associated with the underlying digital asset;and (2) corresponding token balance information associated with saidpublic address information. In embodiments, sixth authorizationinstructions of authorization instructions module 1855 may includeinstructions for modifying the transaction data in response to requestfrom the second contract address (print limiter 1813).

The process may continue with step S2013. At step S2013, fifth smartcontract instructions for the digital asset token for the digital assettoken associated with the blockchain associated with the underlyingdigital asset are provided. In embodiments, the fifth contract addressis the IMPL smart contract 1320 (contract address 2) and the fifth smartcontract instructions of step S2013 are the IMPL Contract instructions1320A-1, both described in connection with FIG. 18F. In embodiments, thefifth smart contract instructions may be saved in the blockchain for theunderlying digital assets and may include (1) token creationinstructions to create tokens of the digital asset tokens underconditions set forth by the print limiter token creation instructions;and (2) second delegation instructions for delegating to anothercontract address, data storage operations. In embodiments, instructionsfrom the PRINT LIMITER Token Creation Instructions Module 1833 may setconditions for the token creation instructions included with the fourthsmart contract instructions (i.e. instructions included in the IMPLToken Creation Instructions Module 1865).

The process described in FIG. 20A-1 may continue with step S2014. Atstep S2014, a digital asset token issuer system increases the totalsupply of the digital asset token from a first amount to a secondamount. Step S2014 is described in more detail in connection with FIGS.20B-C. Increasing the total supply of the digital asset token may beingwith step S2018. At step S2018, a first transaction request may begenerated by the digital asset token issuer system. The generatedtransaction request may include a first message including a firstrequest to increase the total supply of the digital asset token to asecond amount of digital asset tokens. The first transaction requestbeing from the on-line public key address 1825 to the fifth contractaddress (IMPL 1320). In embodiments, the first transaction request maybe signed by the first on-line private key.

In step S2020 the first transaction request is sent by the digital assettoken issuer system, from the on-line public key address 1825 to thefifth contract address (IMPL 1320).

Next, In step S2021, the first transaction request is sent by thedigital asset token issuer system via the underlying blockchain from thefifth contract address (IMPL 1320) to the second contract address (PRINTLIMITER 1360). In embodiments, the second contract address (PRINTLIMITER 1360) executes, via the blockchain 1807, the first transactionrequest to return a first unique lock identifier associated with thefirst transaction request. In embodiments, the first transaction requestmay include first transaction fee information for miners in theblockchain network to process the first transaction request.

Next, In step S2022, the first unique lock identifier may be obtained bythe digital asset token issuer system, based on reference to theblockchain 1807.

In step S2024, a second transaction request may be generated by thedigital asset token issuer system. The generated transaction request mayinclude a second message including a second request to unlock the totalsupply of the digital asset token in accordance with the first requestincluding the first unique lock identifier. The second transactionrequest being from the on-line public key address 1825 to the thirdcontract address (custodian (print limiter) 1350). In embodiments, thesecond transaction request may be signed by the first on-line privatekey.

In step S2026 the second transaction request is sent by the digitalasset token issuer system, from the on-line public key address 1825 tothe third contract address (custodian (print limiter) 1350). Inembodiments, the third contract address (custodian (print limiter) 1350)executes, via the blockchain 1807, the first transaction request toreturn a first unique lock identifier associated with the secondtransaction request to return a first unique request hash associatedwith the second transaction request. In embodiments, the firsttransaction request may include second transaction fee information forminers in the blockchain network to process the second transactionrequest.

Next, In step S2028, the first unique request hash is obtained, by thedigital asset token issuer system, based on reference to the blockchain1807.

The process described in FIG. 20B may continue with step S2030 of FIG.20C. At step S2030, a third transaction request is generated by thedigital asset token issuer system. The third transaction request may bedigitally signed by at least the second designated private key (off-linekeyset 1803) including the first unique request hash.

Next, at step S2032, the third transaction request is transferred fromthe digital asset token issuer system to a first portable memory device.A portable memory device may, in embodiments, be a flash drive, USBdrives, external hard drives, and/or portable CD/DVD-ROM drives, to namea few.

At step 2034, the third transaction request is transferred from thefirst portable memory device to the second computer system. Next, at astep S2036, the third transaction request is digitally signed using thesecond designated private key (off-line keyset 1803) to generate a thirddigitally signed transaction request.

The process of FIGS. 20B and 20C may continue with step S2038. At stepS2038, the third digitally signed transaction request is sent from asecond portable memory device using the digital asset token issuersystem to the third contract address (custodian (print limiter) 1350).

In embodiments, the first portable memory device is the second portablememory device. In embodiments, the first portable memory device is notthe second portable memory device. In embodiments, the third digitallysigned transaction request is returned to the STORE smart contract 1330.Once returned to the STORE smart contract 1330, the third digitallysigned transaction request is returned to the print limiter 1813.

Referring back to FIG. 20A-1, the process may continue with step S2016.At step S2016, the digital asset token issuer system confirms that thetotal supply of digital asset tokens is set to the second amount. Inembodiments, the third smart contract (custodian (print limiter) 1350)executes, via the blockchain network, the third digitally signedtransaction request to validate the second request to unlock based onthe third digitally signed transaction request and the first uniquerequest hash and executes a first call to the second contract address(PRINT LIMITER 1360), to increase the total supply of the digital assettoken to the second amount of digital asset tokens. In embodiments, thesecond contract address (PRINT LIMITER 1360) may return the first callto the fifth contract address (IMPL 1320). In embodiments, the fifthsmart contract (IMPL 1320) executes, via the blockchain network, asecond call to the fourth smart contract address (STORE 1330) to set thetotal supply of the digital asset tokens to the second amount of digitalasset tokens. In embodiments, the fourth smart contract (STORE 1330)executes, via the blockchain, the second call to set the total supply ofthe digital asset tokens to the second amount of digital asset tokens.

In embodiments, the steps of FIGS. 20A and 20B may be rearranged and/oromitted.

Merely for the purposes of description, the following example isprovided.

EXAMPLE 1 Increase the Supply Ceiling by 100 Million Cents

Tx 1. TO = address of PrintLimiter DATA =′requestCeilingRaise(100,000,000)′ (Tx would be signed by Adminstrator's′primary′ key, although there are no restrictions onwho can call thisfunction.) Execution produces a unique lock identifier, say ′lockId1′.

Tx 2. TO = address of (Print)Custodian (instance of the Custodiancontract, with cold tier keys, intended to be the offline custodian ofprinting operations) DATA = ′requestUnlock(lockId1, address ofPrintLimiter, selector for functionconfirmCeilingRaise, ...and a detailI′m going to omit...)′ (Tx would be signed by Adminstrator's ‘primary’key, although there are no restrictions on who can call this function.If it's a not the primary key there is an anti-spam mechanism.)Execution produces a unique request hash, say ′reqMsgHash1. 2 of theoffline keys set up with (Print)Custodian sign ′reqMsgHash1′; we'll namethe signatures ′sig1_a′ and ′sig1_b′ .

Tx 3. TO = address of (Print)Custodian DATA =′completeUnlock(requestMsgHash1, sig1_a, sig1_b)′ (Tx would be signed byAdminstrator's ‘primary’ key, although there are no restrictions on whocan call this function.) Execution validates the signatures (andenforces other details around time locks and revocation). Next, itexecutes a call to PrintLimiter and its confirmCeilingRaise (NOTE thatthose two detailed were fixed in Tx2 as parameters to the call torequestUnlock). CALL ′(address ofPrintLimiter).confirmCeilingRaise(lockId1)′ Execution continues inPrintLimiter in the function ′confirmCeilingRaise′. Storage for thecontract is updated: STORE supply ceiling = current supply ceiling +100,000,000

FIG. 21A is a flowchart of an exemplary process of increasing the totalsupply of digital asset tokens in accordance with exemplary embodimentsof the present invention. The process of FIG. 21A may begin with stepS2102. In step S2102, a first designated key pair (on-line keyset 11362) including a first public key of an underlying digital asset and acorresponding first designated private key is provided. In embodiments,the underlying digital asset is maintained on a distributed publictransaction ledger maintained by a plurality of geographicallydistributed computer systems in a peer-to-peer network in the form ofthe blockchain 1807. In embodiments, the first designated private key isstored on a first computer system which is connected to the distributedpublic transaction ledger through the internet (network 15). Inembodiments, the first designated key pair may be multiple on-line keyswith multiple electronic signatures.

In step S2104, a second designated key pair including a seconddesignated public key (off-line keyset 1803) of the underlying digitalasset and a corresponding second designated private key is provided. Inembodiments, the second designated private key is stored on a secondcomputer system which is physically separated from the first computersystem and is not operatively or physically connected to the distributedpublic transaction ledger or the internet (network 15). In embodiments,the second computer system may be the hardware storage module 1900. Inembodiments, the second designated key pair may be multiple on-line keyswith multiple electronic signatures.

In step S2106, first smart contract instructions for a digital assettoken associated with a first contract address associated with theblockchain associated with the underlying digital asset are provided. Inembodiments, the first contract address is contract address 1 (proxysmart contract) 1809 and first smart contract instructions of step S2106are the proxy contract instructions 1310A-1, both described inconnection with FIG. 18B. The first smart contract instructions, may, besaved in the blockchain 1807 and include first delegation instructionsand first authorization instructions. The first delegation instructionsmay delegate one or more first functions associated with the digitalasset token to one or more delegated contract addresses associated withthe underlying digital asset, the delegated contract addresses, inembodiments, being different than the first contract address. The firstdelegation instructions may be located with first delectationinstructions module 1829 described in connection with FIG. 18B. Thefirst smart contract instructions, may also include first authorizationinstructions for the second designated key pair. The first authorizationinstructions may be located with first authorization instructions module1830 described in connection with FIG. 18B.

In step S2108, a second contract instructions for the digital assettoken associated with a second contract address associated with theblockchain associated with the underlying digital asset is provided. Inembodiments, the second smart contract address is contract address 3(print limiter smart contact) 1813 and the second smart contractinstructions are the print limiter contract instructions 1360A-1, bothdescribed in connection with FIG. 18C. In embodiments, the secondcontract address is not the first contract address. The second smartcontract instructions may be saved in the blockchain 1807 and, asdescribed in connection with the print limiter contract instructions1360A-1 of FIG. 18C (the descriptions of which applying herein),include: (1) token creation instructions; (2) custodian instructions;(3) second delegation instructions; (4) second authorizationinstructions; and (5) third authorization instructions. In embodiments,as described above in connection with print limiter contractinstructions 1360A-1 of FIG. 18C (the description of which applyingherein), the second smart contract instructions may also include: (6)token transfer instructions of token transfer instructions module 1843to transfer tokens of the digital asset token from a first designatedaddress to a second designated address.

In embodiments, as described above in connection with print limitercontract instructions 1360A-1 of FIG. 18C (the description of whichapplying herein), the second smart contract instructions may alsoinclude: (7) token destruction instructions of token destructioninstructions module 1845 to destroy one or more tokens of the digitalasset token. Token destruction instructions, in embodiments, may not belimited to print limiter contract instructions 1360A-1. In embodiments,additional smart contracts may also destroy tokens, such as IMPL smartcontract 1320 (contract address 2), CUSTODIAN 1 smart contract 1819(contract address 5), CUSTODIAN 2 smart contract 1350 (contract address6), and/or CUSTODIAN 3 smart contract 1823 (contract address 7), to namea few.

In embodiments, as described above in connection with print limitercontract instructions 1360A-1 of FIG. 18C (the description of whichapplying herein), the second smart contract instructions may alsoinclude: (8) token balance modification instructions of token balancemodification instructions module 1847 to modify a total number of tokensof the digital asset token assigned to a third designated address.

In step S2110, third smart contract instructions for the digital assettoken associated with a third contract address associated with theblockchain associated with the underlying digital asset are provided. Inembodiments, the third smart contract address is CUSTODIAN 2 smartcontract 1350 (contract address 6) and the second smart contractinstructions are the custodian 2 contract instructions 1350A-1, bothdescribed in connection with FIG. 18D. The third smart contractinstructions may be saved in the blockchain 1807 and, as described inconnection with the custodian 2 smart contract instructions 1350A-1 ofFIG. 18D (the descriptions of which applying herein), include: (1)fourth authorization instructions and (2) fifth authorizationinstructions. The fourth authorization instructions of CUSTODIAN 2 firstauthorization instructions module 1849 (i.e. fourth authorizationinstructions module) may include instructions for the second designatedkey pair to authorize the issuance of instructions to the second smartcontract instructions with respect to token creation. In embodiments,the authorization instructions with respect to token creation may beabove the first threshold during the first time period.

In embodiments, a token creation request may exceed a ceiling (i.e. arequest for 150 tokens when the ceiling is 100 tokens), CUSTODIAN 2smart contract 1350 may authorize an increase in the ceiling. Thisauthorization may be fifth authorization instructions of the CUSTODIAN 2second authorization instructions module 1851 (i.e. fifth authorizationinstructions module), and may include instructions for the seconddesignated key pair (off-line keyset 1803, . . . 1803N) to authorize theissuance of instructions to the first smart contract instructions tochange the one or more designated contract address from the secondcontract address to a different designated contract address. Inembodiments, a ceiling is raised by creating a second print limitersmart contract on the blockchain 1807 with a higher ceiling. Once thesecond print limiter smart contract is created, the request for tokencreation can be routed to the second print limiter smart contract.

A more detailed description of the process of raising the token creationceiling is located above in connection with FIGS. 19A-B, the descriptionof which applying herein.

The process of FIG. 21A may continue with step S2112. At step 2112,fourth smart contract instructions are provided for the digital assettoken associated with a fourth contract address associated with theblockchain associated with the underlying digital asset. In embodiments,the fourth contract address is STORE smart contract 1330 (contractaddress 4) and fourth smart contract instructions of step S2112 are thestore contract instructions 1330A-1, both described in connection withFIG. 18E. The fourth smart contract instructions may include: (1)storage instructions and (2) sixth authorization instructions. Inembodiments, storage instructions of storage instructions module 1853may include instructions for transaction data related to the digitalasset token to be stored. The transaction data may include (for allissued tokens of the digital asset token): (1) public addressinformation associated with the underlying digital asset; and (2)corresponding token balance information associated with said publicaddress information. In embodiments, sixth authorization instructions ofauthorization instructions module 1855 may include instructions formodifying the transaction data in response to request from the secondcontract address (print limiter 1813).

At a step S2114, fifth smart contract instructions are provided for thedigital asset token associated with a fifth contract address associatedwith the blockchain associated with the underlying digital asset. Inembodiments, the fifth smart contract address is IMPL smart contract1320 (contract address 2) and the fifth smart contract instructions areimpl contract instructions 1320A-1.

The process of FIG. 21A may continue with step S2116 of FIG. 21B. Atstep S2116, a request to generate and assign a first amount of digitaltoken to a first designated public address is received by the digitalasset token issuer system. In embodiments, the first designated publicaddress may be User 1 public address 1827, User 1 public address 1827being associated with User 1 Device 1805. In embodiments, a validationrequest may be sent to the on-line key public address 1 1825. Thevalidation request may determine whether the first amount of digitaltoken is available to be generated and assigned. In embodiments, thedigital asset token issuer system may determine whether the on-line keyhas the authority to process the request to generate and assign thefirst amount of digital token. This determination may be made based on avariety of factors, including whether the first amount of digital tokenis actually available and/or the ceiling of digital asset tokens for aspecific time period, to name a few.

At step, S2118, the digital asset token issuer system generates thefirst amount of digital asset token and assigns the first amount ofdigital asset tokens to the first designated public address. Inembodiments, step S2118 may include the digital asset token issuersystem generating a first transaction request. The first transactionrequest, in embodiments, may be address from the online public keyaddress (On-line public address 1 1825) to the fifth contract address(IMPL Smart Contract (Contract Address 2) 1320). The first transactionrequest may include a first message including a first request togenerate the first amount of digital asset token and assign said firstamount of digital asset token to the first designated public address. Inembodiments, the first transaction request is digitally signed by thefirst on-line private key (on-line keyset 1362). After the transactionrequest is generated, the first transaction request may be sent from theonline public key address (On-line public address 1 1825) to the fifthcontract address (IMPL smart contract 1320 (contract address 2)). Inembodiments, the first transaction request includes first transactionfee information for miners in the blockchain network to process thefirst transaction request.

After the first transaction request is received by the fifth contractaddress, in embodiments, the fifth smart contract (IMPL 1320) mayexecute, via the blockchain 1807, the first transaction request tovalidate the first request and the authority of the first on-lineprivate key (on-line keyset 1 1362) to call the second smart contract(print limiter 1813) to execute the first transaction request. Thesecond smart contract (print limiter 1360) may also send a first callrequest to the fifth contract address (IMPL smart contract 1320(contract address 2)) to generate and assign to the first designatedpublic address (user 1 public address 1827) the first amount of digitalasset tokens.

In response to the return call, in embodiments, the fifth smart contract(IMPL smart contract 1320) may execute via the blockchain 1807 the firstcall request to generate a first unique lock identifier. The fifth smartcontract (IMPL smart contract 1320) may return to the second smartcontract address (print limiter 1813) the first unique lock identifier.

In embodiments, in response to the return of the first unique lockidentifier, the second smart contract (print limiter 1360) may execute,via the blockchain 1807, a second call request to the fifth smartcontract address (IMPL smart contract 1320 (contract address 2)) toconfirm the first call request with the first lock identifier.

In response to the second call request, in embodiments, the fifth smartcontract (IMPL smart contract 1320) executes, via the blockchain 1807,the pending first call request to execute a third call request to thefourth contract address (STORE smart contract 1330 (contract address 4))to obtain the total supply of digital asset tokens in circulation.

In embodiments, the fifth smart contract (IMPL 1320) executes, via theblockchain network 1807, the call to execute the first call to execute asecond call to the fourth smart contract (STORE smart contract 1330) toobtain the total supply of digital asset tokens in circulation. Afterexecuting the third call request, the fourth smart contract (STORE smartcontract 1330) returns, to the fifth contract address (IMPL smartcontract 1320 (contract address 2)), a second amount of digital assettokens corresponding to the total supply of digital asset tokens incirculation.

In response to the return of the second amount, in embodiments, thefifth smart contract (IMPL smart contract 1320 (contract address 2))executes via the blockchain 1807 a fourth call request to the fourthcontract address (STORE smart contract 1330 (contract address 4)) to seta new total supply of digital asset tokens in circulation to a thirdamount. The third amount, in embodiments, may be the total of the firstamount and the second amount.

In embodiments, in response to the fourth call request, the fourth smartcontract (STORE smart contract 1330) executes via the blockchain 1807the fourth call request and sets a new total supply of digital assettokens in circulation at the third amount. Once the total supply is setto the third amount, the fourth smart contract (STORE smart contract1330) returns to the fifth contract address (IMPL smart contract 1320(contract address 2)).

The fifth smart contract executes, in embodiments, in response to thereturn, via the blockchain 1807, a fifth call request to the fourthcontract address (STORE smart contract 1330 (contract address 4)) to addthe first amount of digital asset tokens to the balance associated withthe first designated public address.

In embodiments, in response to the fifth call request, the fourth smartcontract (STORE smart contract 1330) executes, via the blockchain 1807,the fifth call request to set the balance of digital asset tokens in thefirst designated public address (user 1 public address 1827) at a fourthamount which includes the addition of the first amount to the previousbalance.

In embodiments, the fourth smart contract (STORE smart contract 1330)returns to the fifth contract address (IMPL smart contract 1320(contract address 2)). Once the fifth contract address receives thereturn, in embodiments, the fifth contract address returns to the secondcontract address (PRINT LIMITER smart contract 1360 (contract address3)).

The process of FIGS. 21A-B may continue with step S2120. At step S2120,the digital asset token issuer system confirms the balance of digitalasset tokens in the first designated public address (user 1 publicaddress 1827) is set to include the first mount of digital asset tokensbased on reference to the blockchain.

In embodiments, the steps of FIGS. 21A and 21B may be rearranged and/oromitted.

EXAMPLE 2 Increase the Token Supply by 10 Million Cents Using an OnlineKey (Assumes the Amount to be Printed Would Not Exceed the CeilingLimit)

Tx 1. TO = address of PrintLimiter DATA = ′limitedPrint(address of User1, 10,000,000)′ (Tx signed by Administrator.., analogous to above)Execution validates that the new supply including 10 million cents wouldnot exceed the ceiling. Next, CALL ′(address ofImpl.).requestPrint(address of User 1, 10,000,000)′ Execution continuesin Impl. in function ′requestPrint′. This function produces a uniquelock identifier, say ′lockId2′. Execution returns from Impl. toPrintLimiter, passing ′lockId2′. Next, in PrintLimiter CALL ′(address ofImpl).confirmPrint(lockId2′. Execution continues in Impl. in function′confirmPrint′. The pending print associated with ′lockId2′ (address ofUser 1, 10,000,000) is retrieved. Next, CALL ′(address ofStore).totalSupply( )′ (Execution continues in Store, in functiontotalSupply, which returns with the value of the total supply) let newsupply = current supply + 10,000,000 Next, CALL ′(address ofStore).setTotalSupply(new supply)′ Execution continues in Store infunction ′setTotalSupply′. STORE total supply = new supply Executionreturns to Impl. Next, CALL ′(address of Store).addBalance(address ofUser 1, 10,000,000)′ Execution continues in Store in function ′addBalance′ . STORE balance of User 1 = balance of User 1 + 10,000,000Execution returns to Impl. (some logging occurs, but let's skip overthis) Execution returns to PrintLimiter and terminates.

In embodiments, the process of FIGS. 21A-B may further include theprocess described in connection with FIG. 19D. The process starts withthe blockchain 1807 receiving, from a first user device associated withthe first designated public address via the blockchain, a secondtransaction request 1937. The first user device, may be user device 11805. The first designated public address may be user 1 public address1827. The second transaction request may be addressed from the firstdesignated public address to the first contract address (contractaddress 1 (proxy smart contract) 1809). In embodiments, the secondtransaction request may include a second message including a secondrequest to transfer a fifth amount of digital assets from the firstdesignated public address to a second designated public address. Thesecond transaction request may be digitally signed by a first userprivate key. In embodiments, the first user private key may bemathematically related to first designated public address (user 1 publicaddress 1827). In embodiments, the first user device 1805 has access tothe first user private key prior to sending the second transactionrequest. In embodiments, the second transaction request includes secondtransaction fee information for miners in the blockchain network toprocess the second transaction request.

Once the second transaction request is sent, the first smart contractaddress (contract address 1 (proxy smart contract) 1809) executes, viathe blockchain 1807, the second transaction request to execute 1939, viathe blockchain 107 a sixth call request to the fifth contract address(IMPL smart contract 1320 (contract address 2)) to transfer a fifthamount of digital assets form the first designated public address (User1 public address 1827) to the second designated public address (User Xpublic address 1827X). As shown in FIG. 19D, the proxy smart contract1310 calls the IMPL smart contract 1320 to perform afunction—transferWithSender(user 1 address, user 2 address, 1000).

In response to the sixth call request, the fifth smart contract (IMPLsmart contract 1320 (contract address 2)) executes, via the blockchain1807, authorization instructions to verify the sixth call came from anauthorized contract address, and, upon verification, executes a seventhcall request 1941 to the fourth contract address (STORE smart contract1330 (contract address 4)) to obtain a sixth amount of digital assettokens which reflect a current balance of digital asset tokensassociated with the first designated public address. As shown in FIG.19D, the IMPL smart contract 1320 calls the STORE smart contract 1330 todetermine the balance associated with the user 1 public address.

In response to receiving the seventh call request, the fourth smartcontract address (STORE smart contract 1330 (contract address 4))executes 1943, via the blockchain 1807, the seventh call request toreturn the sixth amount of digital asset tokens. As shown in FIG. 19D,the store smart contract returns the balance associated with the user 1address, which, in the case of the example shown in connection with FIG.19D, is 3000.

In response to the return of the sixth amount of digital asset, thefifth smart contract (IMPL smart contract 1320 (contract address 2))executes 1945, via the blockchain 1807, a balance verificationinstruction to confirm that the fifth amount of digital asset tokens isless than or equal to the sixth amount of digital asset tokens. In thecase where the fifth amount of digital asset tokens is less than orequal to the sixth amount of digital asset tokens, the fifth smartcontract executes, via the blockchain network 1807, a seventh callrequest to the fourth contract address (STORE smart contract 1330(contract address 4)) to set a new balance for the digital asset tokensin the first designated public address to a seventh amount which equalsthe sixth amount less the fifth amount. As shown in FIG. 19D, the IMPLsmart contract 1320 verifies that user 1 has a sufficient balance. Theuser balance in this example is 3000. The transfer request is for 1000.Thus, user 1 has a sufficient balance to transfer. Once verified, theIMPL smart contract 1320 sets the user 1 balance at 2000 (the originaluser balance 3000 less the transfer request amount 1000).

In response to the seventh call, the fourth smart contract (STORE smartcontract 1330) executes 1947, via the blockchain 1807, the seventh callto set and store the new balance for the first designated public addressas the seventh amount and returns the new balance for the firstdesignated public address as the seventh amount. As shown in FIG. 19D,the store smart contract sets the user 1 balance as the seventh amount(2000).

In response to the return of the new balance, the fifth smart contract(IMPL smart contract 1320) executes 1949, via the blockchain 1807, aneighth call to add the second amount of digital asset tokens to thebalance associated with the second designated public address (User Xpublic address 1827X) at a seventh amount which includes the addition ofthe second amount to a previous balance associated with the seconddesignated public address. As shown in FIG. 19D, the IMPL smart contract1320 calls the store smart contract to add the transfer amount (1000) tothe balance associated with the second user address.

In response to receiving the either call, the store smart contractexecutes the eighth call and sets the balance associated with the seconduser to the balance before the transfer and the transfer amount 1951.

In embodiments, the STORE smart contract 1330 returns to the IMPL smartcontract 1320. In response to the return, the IMPL smart contract 1320may log the new balance associated with the second user 1953. Inembodiments, the IMPL smart contract 1320 may then return to the proxysmart contract 1310.

In embodiments, once the transfer has been completed, the first userdevice (user 1 device 1805) may confirm that the balance of digitalasset tokens in the first designated public address is the sixth amountof digital asset tokens based on reference to the blockchain 1807.Similarly, the second user device (user X device 1805X) may also confirmthat the balance of digital asset tokens in the second designated publicaddress is the seventh amount of digital asset tokens based on referenceto the blockchain 1807.

EXAMPLE User 1 Transfers 1,000 Cents to User 2

Tx 1. TO = address of Proxy DATA = ′transfer(address of User 2, 1,000)′Tx signed by User 1 private key, therefore FROM = address of User 1public key Execution immediately jumps to Impl. CALL ′(address ofImpl.).transferWithSender(address of User 1, address of User 2, 1,000)′Execution continues in Impl. in function ′transferWithSender′. Thisfunction validates that it was called by the sender it trusts, so itchecks that sender is address of Proxy. Next, CALL ′(address ofStore).balances(address of User 1)′ (Execution continues in Store, infunction ′balances′, which returns the balance associated with theaddress of User 1) Execution returns and continues in Impl where theretrieved balance value is compared to 1,000 to check that User 1 has atleast 1,000 tokens. let new balance of User 1 = balance of User 1 -1,000 Next, CALL ′(address of Store).setBalance(address of User 1, newbalance of User 1)′ Execution continues in Store in function ′setBalance′. (function checks that it was called by the sender ittrusts, the active Impl.) STORE balance of User 1 = new balance of User1 Execution returns to Impl. Next, CALL ′(address ofStore).addBalance(address of User 2, 1,000)′ Execution continues inStore in function ′ addBalance′. (function checks that it was called bythe sender it trusts...) STORE balance of User 2 = balance of User 2 +1,000 Execution returns to Impl. (some logging occurs, but let's skipover this) Execution returns to Proxy and terminates.

In embodiments, the process of FIGS. 21A-B may further include theprocess described in connection with FIG. 19E. In embodiments, theprocess may begin with providing a third designated key pair. The thirddesignated key pair, in embodiments, may include a third designatedpublic key of the underlying digital asset and a corresponding thirddesignated private key. The third designated private key may be storedon a third computer system which is connected to the distributed publictransaction ledger through the internet (network 15). In embodiments,the third designated key pair may be the first designated key pair. Inembodiments, the third designated key pair may be the second designatedkey pair. In embodiments, the third computer system may be the firstcomputer system. In embodiments, the third computer system is not thefirst computer system. In embodiments, the administrator system 1801includes the first computer system and the third computer system.

The blockchain 1807 may receive a second transaction request 1955 by theblockchain 1807 from the third computer system (i.e. user device 1). Thesecond transaction request may include a second message including asecond request to burn a fifth amount of digital asset tokens from abalance associated with the third designated public key address. Thesecond transaction request may be sent from the third designated publickey address to the fifth contract address (IMPL smart contract 1320(contract address 2)). The second transaction request, in embodiments,is digitally signed by a third designated private key.

In response to receiving the second transaction request, the fifth smartcontract (IMPL smart contract 1320) executes 1957, via the blockchain1807, the second transaction request to execute, via the blockchain1807, a sixth call request to the fourth contract address (STORE smartcontract 1330 (contract address 4)) to obtain a sixth amount of digitalasset tokens which reflect a current balance of digital asset tokensassociated with the third designated public key address. As shown inFIG. 19E, the IMPL smart contract 1320 calls the store contract address1815 to request a balance of digital asset tokens associated with thethird designated public address (address 1).

In response to the sixth call request, the fourth smart contract (STOREsmart contract 1330), executes 1959 via the blockchain 1807, the seventhcall request to return the sixth amount of digital asset tokens. Asshown in FIG. 19E, the STORE smart contract 1330 determines that thebalance associated with the third designated public address is 3000. TheSTORE smart contract 1330 returns the amount (3000) to the IMPL smartcontract 1320.

In response to the return of the sixth amount of digital asset, thefifth smart contract (IMPL smart contract 1320) executes 1961, via theblockchain 1807, a balance verification instruction to confirm that thefifth amount of digital asset tokens is less than or equal to the sixthamount of digital asset tokens. In the case where the fifth amount ofdigital asset tokens is less than or equal to the sixth amount ofdigital asset tokens, the fifth smart contract (IMPL smart contract1320) executes, via the blockchain 1807, a seventh call request to thefourth contract address (STORE smart contract 1330 (contract address 4))to set a new balance for the digital asset tokens in the thirddesignated public key address to a seventh amount which equals the sixthamount less the fifth amount. As shown in FIG. 19E, the IMPL smartcontract 1320 verifies that the third designated public address (address1) has as sufficient balance because 1000 is less than the currentbalance of 3000. The IMPL smart contract 1320 then executes a call toset the balance of associated with the third designated public address(address 1) to 2000 (3000 less 1000 equals 2000).

In response to the seventh call, the fourth smart contract (STORE smartcontract 1330) executes 1963, via the blockchain 1807, the seventh callto set and store the new balance for the third designated public keyaddress as the seventh amount and returns the new balance for the thirddesignated public key address as the seventh amount. As shown in FIG.19E, the STORE smart contract 1330 stores the new balance as 2000 andreturns to the IMPL smart contract 1320.

In response to the return of the new balance, the fifth smart contract(IMPL smart contract 1320) executes 1965, via the blockchain 1807, aneighth call request to the fourth contract address (STORE smart contract1330 (contract address 4)) to obtain a total supply of digital assettokens in circulation. As shown in FIG. 19E, the IMPL smart contract1320 calls the STORE smart contract 1330, requesting a total supply ofdigital asset tokens.

In response to the eighth call request, the fourth smart contract (STOREsmart contract 1330) executes 1967, via the blockchain 1807 the eightcall request and returns, to the fifth contract address (IMPL smartcontract 1320 (contract address 2)), an eighth amount of digital assettokens corresponding to the total supply of digital asset tokens incirculation. As shown in FIG. 19E, the STORE smart contract 1330determines that the total supply of tokens is 10,000 and returns thatvalue to the IMPL smart contract 1320.

In response to the return of the eighth amount, the fifth smart contract(IMPL smart contract 1320) executes 1969, via the blockchain, a ninthcall request to the fourth contract address (STORE smart contract 1330(contract address 4)) to set a new total supply of digital asset tokensin circulation to a ninth amount, which is the eighth amount less thefifth amount. As shown in FIG. 19E, the IMPL smart contract 1320 callsthe STORE smart contract 1330 to set the total supply of the digitalasset tokens to 9,000 (10,000 less 1,000).

In response to the ninth call request, the fourth smart contract (STOREsmart contract 1330) executes 1971, via the blockchain 1807, the ninthcall request and sets a new total supply of digital asset tokens incirculation at the ninth amount and returns to the fifth contractaddress (IMPL smart contract 1320 (contract address 2)). In embodiments,the token balance modification instructions module 1847 balances thedeposits and withdrawals at a predetermined time (i.e. end of the day orclose of business).

In response to receiving a return from the STORE smart contract 1330,the IMPL smart contract 1320 logs 1973 the new total supply of digitalasset tokens in circulation.

EXAMPLE Reduce the Token Supply by 1,000,000 Cents

Tx 1. TO = address of Impl. DATA = ′burn(1,000,000)′ (Tx is signed bythe key of the address that is going to sacrifice some of its balance.)let address of sender = address of key that signed Tx 1. Executionimmediately jumps to Store CALL ′(address of Store).balances(address ofsender)′ (Execution continues in Store, in function ′balances′, whichreturns the balance associated with the sender) Execution returns andcontinues in Impl where the retrieved balance value is compared to theburn amount of 1,000,000 to check that the sender has at least 1,000,000tokens. let new balance of sender = balance of sender - 1,000,000 Next,CALL ′(address of Store).setBalance(address of sender, new balance ofsender)′ Execution continues in Store in function ′setBalance′.(function checks that it was called by the sender it trusts, the activeImpl.) STORE balance of sender = new balance of sender Execution returnsto Impl. Next, Call ′(address of Store).totalSupply( )′ (Executioncontinues in Store, in function ′totalSupply′, which returns with thevalue of the total supply) let new supply = current supply + 1,000,000Next, CALL ′(address of Store).setTotalSupply(new supply)′ Executioncontinues in Store in function ′setTotal Supply′. STORE total supply =new supply Execution returns to Impl. (some logging occurs, but let'sskip over this) And execution terminates.

EXAMPLE Change the Impl that Proxy Delegates to

Tx 1. TO = address of Proxy DATA = ′requestImplChange( address ofImpl_V2)′ (Tx would be signed by Adminstrator's ‘primary’ key, althoughthere are no restrictions on who can call this function.) Executionproduces a unique lock identifier, say ′lockId3′.

Tx 2. TO = address of (Upgrade)Custodian (instance of the Custodiancontract, with cryo tier keys, intended to be the offline custodian ofupgrade operations) DATA = ′requestUnlock(lockId3, address of Proxy,selector for function confirmImplChange,...and a detail I'm going toomit...)′ (Tx would be signed by Adminstrator's ′primary′ key, althoughthere are no restrictions on who can call this function. If it's a notthe primary key there is an anti-spam mechanism.) Execution produces aunique request hash, say ′reqMsgHash2′. 2 of the offline keys set upwith (Upgrade)Custodian sign ′reqMsgHash2′; we'll name the signatures′sig2_a′ and ′ sig2_b′. Tx 3. TO = address of (Upgrade)Custodian DATA =′completeUnlock(requestMsgHash2, sig2_a, sig2_b)′ (Tx would be signed byAdminstrator's ‘primary’key, although there are no restrictions on whocan call this function.) Execution validates the signatures (andenforces other details around time locks and revocation). Next, itexecutes a call to Proxy and its confirmImplChange (NOTE that those twodetailed were fixed in Tx2 as parameters to the call to requestUnlock).CALL ′(address of Proxy).confirmImplChange(lockId3)′ Execution continuesin PrintLimiter in the function ′confirmImplChange′. Storage for theactive implementation address is updated: STORE impl = address ofImpl_V2 (some logging occurs, but let's skip over this) Executionreturns to (Upgrade)Custodian (some logging occurs, but let's skip overthis) Execution terminates.

FIG. 19C is a schematic drawing of an exemplary process of limiting theprint limiter with respect to a public address in accordance withexemplary embodiments of the present invention. The process at FIG. 19Cmay begin with a first transaction request 1917 by an administratorsystem 1801 to blockchain 1807. The first transaction request may befrom on-line key public address 1825 to PRINT LIMITER smart contract1360 (contract address 3). In embodiments, the first transaction requestmay include a message requesting the limited print of 10 million digitalasset tokens to user 1 public address 1827.

In response to receiving the first transaction request, the PRINTLIMITER smart contract 1360 executes 1919 a first call request, via theblockchain 1807, to the impl smart contract address 1811 to print 10million digital asset tokens to user 1 public address 1827. In responseto receiving the first call request, the impl returns a lockID 1921 tothe print limiter smart contract address 1813.

In response to receiving the lockID, the print limiter smart contractexecutes 1923 a second call request, via the blockchain 1807, to theimpl smart contract address 1811 to confirm the print of 10 milliondigital asset tokens using the lockID.

In response to receiving the second call, the IMPL smart contract 1320retrieves the pending request to print 10 million digital asset tokensand executes 1925, via the blockchain 1807, a third call request to thestore smart contract address 1815 to determine the total supply ofdigital asset tokens.

In response to receiving the third call, the STORE smart contract 1330determines 1927 the total supply of digital asset tokens to be 100million digital asset tokens. The total supply amount determined by theSTORE smart contract 1330 is then returned by the STORE smart contract1330 to the impl smart contract address 1811.

In response to receiving the return from the store smart contractaddress 1815, the impl smart contract address executes 1929, via theblockchain, a fourth call request to set the total supply of digitalasset tokens to 110 million, the original total supply 100 million plusthe requested print amount of 10 million. The fourth call request may besent to the store smart contract address 1815.

In response to receiving the fourth call request, the STORE smartcontract 1330 sets 1931 the total supply of digital asset tokens to 110million digital asset tokens and returns to the impl smart contractaddress 1811.

In response to receiving the return from the store smart contractaddress 1815, the impl smart contract may execute 1933 a fifth call toadd the newly printed 10 million digital asset tokens to user 1 publicaddress 1827. The call may be sent to the store smart contract address1815.

In response to receiving the fifth call to add the 10 million digitalasset tokens to user 1 public address 1827, the STORE smart contract1330 may store 1935 a new balance associated with the user 1 publicaddress 1827, the new balance being the original balance plus the 10million digital asset tokens. The STORE smart contract 1330 may thenreturn to the impl smart contract address 1811. In response to receivingthe return from the STORE smart contract 1330, the impl smart contractmay return to the print limiter smart contract public address 1813.

In embodiments, the steps of FIGS. 19A through 19E may be rearrangedand/or omitted. In embodiments, any of the smart contracts may beprovided at any of the contract addresses, for example, the fourthcontract address may correspond to the IMPL smart contract while fifthcontract address may correspond to the STORE smart contract. Inembodiments, one or more smart contract may be combined with one of moreother smart contract.

Blockchain Based Financial Instrument

In embodiments, a digital asset in the form of a token (“SecurityToken”) may be issued to represent inventory, equity interests in aventure, real estate, rights in intellectual property such music,videos, pictures, to name a few. When used as a security, appropriatefilings with a regulatory authority may be necessary to comply withlocal law. In the case of a security, investors may exchange fiat orother digital assets (such as bitcoin or ether, to name a few) inexchange for Security Tokens. Typically, Security Tokens may issue usinga smart contract written on another digital asset (such as ether orbitcoin, to name a few), and tracked in a separate database stored in adistributed peer to peer network in the form of a blockchain. In anexample, the blockchain is the Ethereum Blockchain and includes allSecurity Tokens, the respective address associated therewith, whereinmaintenance of the blockchain is controlled by contract instructionsstored in the form of a smart contract at the Contract Address. Inembodiments, the Secure Token database maintained on the blockchain maybe viewed via etherscan.io. In embodiments, the Security Token ledgermay be maintained as a sidechain in a separate database off chain andpublished periodically or aperiodically to the blockchain. Each SecurityToken may also be associated with a specific digital asset address onthe network associated with the underlying digital asset (e.g., theEthereum Network when ether is the underlying digital asset, or theBitcoin Network, when bitcoin is the digital asset, to name a few).Generally, the same blockchain will be used for the SVCoin and theSecurity Token.

Digital Asset Accounts and Transaction Security

Digital assets may be associated with a digital asset account, which maybe identified by a digital asset address. A digital asset account cancomprise at least one public key and at least one private key, e.g.,based on a cryptographic protocol associated with the particular digitalasset system, as discussed herein. One or more digital asset accountsmay be accessed and/or stored using a digital wallet, and the accountsmay be accessed through the wallet using the keys corresponding to theaccount.

Public Keys

A digital asset account identifier and/or a digital wallet identifiermay comprise a public key and/or a public address. Such a digital assetaccount identifier may be used to identify an account in transactions,e.g., by listing the digital asset account identifier on a decentralizedelectronic ledger (e.g., in association with one or more digital assettransactions), by specifying the digital asset account identifier as anorigin account identifier, and/or by specifying the digital assetaccount identifier as a destination account identifier, to name a few.The systems and methods described herein involving public keys and/orpublic addresses are not intended to exclude one or the other and areinstead intended generally to refer to digital asset accountidentifiers, as may be used for other digital math-based asset. A publickey may be a key (e.g., a sequence, such as a binary sequence or analphanumeric sequence) that can be publicly revealed while maintainingsecurity, as the public key alone cannot decrypt or access acorresponding account. A public address may be a version of a publickey. In embodiments, a public key may be generated from a private key,e.g., using a cryptographic protocol, such as the Elliptic Curve DigitalSignature Algorithm (“ECDSA”).

In exemplary embodiments using bitcoin, a public key may be a 512-bitkey, which may be converted to a 160-bit key using a hash, such as theSHA-256 and/or RIPEMD-160 hash algorithms. The 160-bit key may beencoded from binary to text, e.g., using Base58 encoding, to produce apublic address comprising non-binary text (e.g., an alphanumericsequence). Accordingly, in embodiments, a public address may comprise aversion (e.g., a shortened yet not truncated version) of a public key,which may be derived from the public key via hashing or other encoding.In embodiments, a public address for a digital wallet may comprisehuman-readable strings of numbers and letters around 34 characters inlength, beginning with the digit 1 or 3, as in the example of175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W. The matching private key may bestored in a digital wallet or mobile device and protected by a passwordor other techniques and/or devices for providing authentication.

In embodiments, other cryptographic algorithms may be used such as:

-   -   (1) The elliptic curve Diffie-Hellman (ECDH) key agreement        scheme;    -   (2) The Elliptic Curve Integrated Encryption Scheme (ECIES),        also known as Elliptic Curve Augmented Encryption Scheme or        simply the Elliptic Curve Encryption Scheme;    -   (3) The Elliptic Curve Digital Signature Algorithm (ECDSA) which        is based on the Digital Signature Algorithm;    -   (4) The deformation scheme using Harrison's p-adic Manhattan        metric;    -   (5) The Edwards-curve Digital Signature Algorithm (EdDSA) which        is based on Schnorr signature and uses twisted Edwards curves;    -   (6) The ECMQV key agreement scheme which is based on the MQV key        agreement scheme; and    -   (7) The ECQV implicit certificate scheme.

In other digital asset networks, other nomenclature mechanisms may beused, such as a human-readable string of numbers and letters around 34characters in length, beginning with the letter L for Litecoin or M or Nfor Namecoin or around 44 characters in length, beginning with theletter P for PPCoin, to name a few.

Private Keys

A private key in the context of a digital math-based asset, such asbitcoin, may be a sequence such as a number that allows the digitalmath-based asset, e.g., bitcoin, to be transferred or spent. Inembodiments, a private key may be kept secret to help protect againstunauthorized transactions. In a digital asset system, a private key maycorrespond to a digital asset account, which may also have a public keyor other digital asset account identifier. While the public key may bederived from the private key, the reverse may not be true.

In embodiments related to the Bitcoin system, every Bitcoin publicaddress has a matching private key, which can be saved in the digitalwallet file of the account holder. The private key can be mathematicallyrelated to the Bitcoin public address and can be designed so that theBitcoin public address can be calculated from the private key, butimportantly, the same cannot be done in reverse. In the event that atransaction is sent to a Bitcoin public address and signed by a privatekey that does not match, such transaction will not be processed by theBitcoin blockchain.

A digital asset account, such as a multi-signature account, may requirea plurality of private keys to access it. In embodiments, any number ofprivate keys may be required. An account creator may specify the numberof required keys (e.g., 2, 3, 5, to name a few) when generating a newaccount. More keys may be generated than are required to access and/oruse an account. For example, 5 keys may be generated, and anycombination of 3 of the 5 keys may be sufficient to access a digitalasset account. Such an account setup can allow for additional storageand security options, such as backup keys and multi-signaturetransaction approval, as described herein.

Because a private key provides authorization to transfer or spenddigital assets such as bitcoin, security of the private key can beimportant. Private keys can be stored via electronic computer files, butthey may also be short enough that they can be printed or otherwisewritten on paper or other media. An example of a utility that allowsextraction of private keys from an electronic wallet file for printingpurposes is Pywallet. Other extraction utilities may also be usedconsistent with the present invention.

In embodiments, a private key can be made available to a program orservice that allows entry or importing of private keys in order toprocess a transaction from an account associated with the correspondingpublic key. Some wallets can allow the private key to be importedwithout generating any transactions while other wallets or services mayrequire that the private key be swept. When a private key is swept, atransaction is automatically broadcast so that the entire balance heldby the private key is sent or transferred to another address in thewallet and/or securely controlled by the service in question.

In embodiments, using Bitcoin clients, such as BlockChain.info's MyWallet service and Bitcoin-QT, a private key may be imported withoutcreating a sweep transaction.

In embodiments, a private key, such as for a Bitcoin account, may be a256-bit number, which can be represented in one or more ways. Forexample, a private key in a hexadecimal format may be shorter than in adecimal format. For example, 256 bits in hexadecimal is 32 bytes, or 64characters in the range 0-9 or A-F. The following is an example of ahexadecimal private key:

-   -   E9 87 3D 79 C6 D8 7D C0 FB 6A 57 78 63 33 89 F4 45 32 13 30 3D        A6 1F 20 BD 67 FC 23 3A A3 32 62

In embodiments, nearly every 256-bit number is a valid private key.Specifically, any 256-bit number between 0x1 and 0xFFFF FFFF FFFF FFFFFFFF FFFF FFFF FFFE BAAE DCE6 AF48 A03B BFD2 5E8C D036 4141 is a validprivate key. In embodiments, the range of valid private keys can begoverned by the secp256k1 ECDSA standard used by Bitcoin. Otherstandards may also be used.

In embodiments, a shorter form of a private key may be used, such as abase 58 Wallet Import format, which may be derived from the private keyusing Base58 and/or Base58Check encoding. The Wallet Import format maybe shorter than the original private key and can include built-in errorchecking codes so that typographical errors can be automaticallydetected and/or corrected. For private keys associated with uncompressedpublic keys, the private key may be 51 characters and may start with thenumber 5. For example, such a private key may be in the followingformat:

-   -   5Kb8kLf9zgWQnogidDA76MzPL6TsZZY36hWXMssSzNydYXYB9KF

In embodiments, private keys associated with compressed public keys maybe 52 characters and start with a capital L or K.

In embodiments, when a private key is imported, each private key mayalways correspond to exactly one Bitcoin public address. In embodiments,a utility that performs the conversion can display the matching Bitcoinpublic address.

The Bitcoin public address corresponding to the sample above is:

-   -   1CC3X2gu58d6wXUWMffpuzN9JAfTUWu4Kj

In embodiments, a mini private key format can be used. Not every privatekey or Bitcoin public address has a corresponding mini private key; theyhave to be generated a certain way in order to ensure a mini private keyexists for an address. The mini private key is used for applicationswhere space is critical, such as in QR codes and in physical bitcoin.The above example has a mini key, which is:

-   -   SzavMBLoXU6kDrqtUVmffv

In embodiments, any bitcoin sent to the designated address1CC3X2gu58d6wXUWMffpuzN9JAfTUWu4Kj can be transferred or spent byanybody who knows the private key in any of the three formats (e.g.,hexadecimal, base 58 wallet format, or mini private key). That includesbitcoin presently at the address, as well as any bitcoin that are eversent to it in the future. The private key is only needed to transfer orspend the balance, not necessarily to see it. In embodiments, thebitcoin balance of the address can be determined by anybody with thepublic Block Explorer athttp://www.blockexplorer.com/address/lCC3X2gu58d6wXUWMffpuzN9JAfTUWu4Kj—evenif without access to the private key.

In embodiments, a private key may be divided into segments, encrypted,printed, and/or stored in other formats and/or other media, as discussedherein.

Digital Wallets

In embodiments, digital math-based assets can be stored and/ortransferred using either a website or software, such as downloadedsoftware. The website and/or downloadable software may comprise and/orprovide access to a digital wallet. Each digital wallet can have one ormore individual digital asset accounts (e.g., digital asset addresses)associated with it. Each user can have one or more digital wallets tostore digital math-based assets, digital cryptocurrency, assets and thelike and/or perform transactions involving those currencies or assets.In embodiments, service providers can provide services that are tied toa user's individual account.

Digital wallets and/or the digital asset accounts associated with and/orstored by a digital wallet may be accessed using the private key (whichmay be used in conjunction with a public key or variant thereof).Accordingly, the generation, access, use, and storage of digital assetaccounts is described herein with respect to generation, access, use,and storage of digital wallets. Such descriptions are intended to berepresentative of digital asset accounts and not exclusive thereof.

A digital wallet can be generated using a digital asset client 110(e.g., a Bitcoin client). In embodiments, a digital wallet can becreated using a key pair system, such as an asymmetric key pair like apublic key and a private key. The public key can be shared with othersto designate the address of a user's individual account and/or can beused by registries and/or others to track digital math-based assettransactions involving a digital asset account associated with thedigital wallet. Such transactions may be listed or otherwise identifiedby the digital wallet. The public key may be used to designate arecipient of a digital asset transaction. A corresponding private keycan be held by the account holder in secret to access the digital walletand perform transactions. In embodiments, a private key may be a 256-bitnumber, which can be represented by a 64-character hexadecimal privatekey and/or a 51-character base-58 private key. As discussed herein,private keys of other lengths and/or based on other numbering systemscan be used, depending upon the user's desire to maintain a certainlevel of security and convenience. Other forms of key pairs, or securitymeasures can be used consistent with embodiments of the presentinvention.

In embodiments, a digital wallet may store one or more private keys orone or more key pairs which may correspond to one or more digital assetaccounts.

In embodiments, a digital wallet may be a computer software wallet,which may be installed on a computer. The user of a computer softwarewallet may be responsible for performing backups of the wallet, e.g., toprotect against loss or destruction, particularly of the private and/orpublic key. In embodiments, a digital wallet may be a mobile wallet,which may operate on a mobile device (e.g., mobile phone, smart phone,cell phone, iPod Touch, PDA, tablet, portable computer, to name a few).In embodiments, a digital wallet may be a website wallet or a webwallet. A user of a web wallet may not be required to perform backups,as the web wallet may be responsible for storage of digital assets.Different wallet clients may be provided, which may offer differentperformance and/or features in terms of, e.g., security, backup options,connectivity to banks or digital asset exchanges, user interface, and/orspeed, to name a few.

In embodiments, a digital wallet may be a custodial digital wallet.Further, the custodial digital wallet may be a segregated custodialwallet or a commingled custodial wallet. Segregated custodial digitalwallets hold digital assets for the benefit of a single customer orentity. Commingled custodial accounts hold digital assets for multipleusers or customers of the custodian. Segregated custodial wallets areuseful for institutional clients, mutual funds and hedge funds, forexample.

While many digital asset holders may hold their digital assets in theirown wallets, various custodial services, like Gemini custodial servicesexist. In embodiments, the present invention may be used with custodialwallets. In embodiments, custodial wallets may be commingled custodialwallets which commingle digital assets from more than one client. Inembodiments, custodial wallets may be segregated custodial wallets, inwhich digital assets for a specific client is held using one or moreunique digital asset addresses maintained by the custodial service. Forsegregated custodial wallets, the amount of digital assets held in suchwallet(s) may be verified and audited on their respective blockchain. Inembodiments, segregated custodial accounts may be used for digital assetholders such as hedge funds, mutual funds, exchange traded funds, toname a few. Proof of control as described herein may be implemented toverify the amount of assets held in custodial wallets, including bothsegregated custodial wallets and commingled custodial wallets.

Signatures

A transaction may require, as a precondition to execution, a digitalasset signature generated using a private key and associated public keyfor the digital asset account making the transfer. In embodiments, eachtransaction can be signed by a digital wallet or other storage mechanismof a user sending a transaction by utilizing a private key associatedwith such a digital wallet. The signature may provide authorization forthe transaction to proceed, e.g., authorization to broadcast thetransaction to a digital asset network and/or authorization for otherusers in a digital asset network to accept the transaction. A signaturecan be a number that proves that a signing operation took place. Asignature can be mathematically generated from a hash of something to besigned, plus a private key. The signature itself can be two numbers suchas r and s. With the public key, a mathematical algorithm can be used onthe signature to determine that it was originally produced from the hashand the private key, without needing to know the private key. Signaturescan be either 73, 72, or 71 bytes long, to name a few.

In embodiments, the ECDSA cryptographic algorithm may be used to ensurethat digital asset transactions (e.g., bitcoin transactions) can only beinitiated from the digital wallet holding the digital assets (e.g.,bitcoin). Alternatively, or in addition, other algorithms may beemployed.

In embodiments, a transaction from a multi-signature account may requiredigital asset signatures from a plurality of private keys, which maycorrespond to the same public key and/or public address identifying themulti-signature digital asset account. As described herein, a greaternumber of private keys may be created than is necessary to sign atransaction (e.g., 5 private keys created and only 3 required to sign atransaction). In embodiments, private keys for a multi-signature accountmay be distributed to a plurality of users who are required to authorizea transaction together. In embodiments, private keys for amulti-signature account may be stored as backups, e.g., in securestorage, which may be difficult to access, and may be used in the eventthat more readily obtainable keys are lost. As noted above, there are avariety of cryptographic algorithms that may be used.

Market Places

A digital asset market place, such as a Bitcoin market place, cancomprise various participants, including users, vendors, exchanges,exchange agents, and/or miners/mining pools. The market contains anumber of digital asset exchanges, which facilitate trade of digitalassets using other currencies, such as United States dollars. Exchangesmay allow market participants to buy and sell digital assets,essentially converting between digital assets (e.g., bitcoin) andcurrency, legal tender, and/or traditional money (e.g., cash). Inembodiments, a digital asset exchange market can include a globalexchange market for the trading of digital assets, which may containtransactions on electronic exchange markets. In embodiments, a digitalasset exchange market can also include regional exchange markets for thetrading of digital assets, which may contain transactions on electronicexchange markets. In accordance with the present invention, exchangesand/or transmitters may also be used to facilitate other transactionsinvolving digital assets, such as where digital assets are beingtransferred from differently denominated accounts or where the amount totransfer is specified in a different denomination than the digital assetbeing transferred, to name a few. Gemini Trust Company LLC (“Gemini”) at(www.gemini.com) is an example of a digital asset exchange 130. Byexample, registered users of Gemini may buy and sell digital assets suchas Bitcoin and Ether in exchange for fiat such as U.S. dollars or otherdigital assets, such as Ether and Bitcoin, respectively. A Bitcoinexchange agent 135 can be a service that acts as an agent for exchanges,accelerating the buying and selling of bitcoin as well as the transferof funds to be used in the buying and/or selling of bitcoin. Coinbase isan example of a company that performs the role of a Bitcoin exchangeagent 135. Coinbase engages in the retail sale of bitcoin, which itobtains, at least in part, from one or more exchanges. FIG. 3illustrates an exemplary Coinbase website interface for buying bitcoin.Other Coinbase options include “Sell Bitcoin,” “Send Money,” “RequestMoney,” and “Recurring Payments.” Other options could also be madeavailable consistent with exemplary embodiments of the presentinvention.

In addition to the services that facilitate digital asset transactionsand exchanges with cash, digital asset transactions can occur directlybetween two users. In exemplary uses, one user may provide payment of acertain number of digital assets to another user. Such a transfer mayoccur by using digital wallets and designating the public key of thewallet to which funds are being transferred. As a result of thecapability, digital assets may form the basis of business and othertransactions. Digital math-based asset transactions may occur on aglobal scale without the added costs, complexities, time and/or otherlimits associated with using one or more different currencies.

Vendors 140 may accept digital assets as payment. A vendor 140 may be aseller with a digital wallet that can hold the digital asset. Inembodiments, a vendor may use a custodial wallet. In embodiments, avendor 140 may be a larger institution with an infrastructure arrangedto accept and/or transact in digital assets. Various vendors 140 canoffer banknotes and coins denominated in bitcoin; what is sold is reallya Bitcoin private key as part of the coin or banknote. Usually, a sealhas to be broken to access the Bitcoin private key, while the receivingaddress remains visible on the outside so that the bitcoin balance canbe verified. In embodiments, a debit card can be tied to a Bitcoinwallet to process transactions.

Digital Asset Exchange

In embodiments, one form of trusted entity that may be an issuer ofSVCoin or an agent of the issuer is a digital asset exchange or bank. Inembodiments, the trusted entity may maintain an SVCoin database on ablockchain. In embodiments, the trusted entity may maintain the SVCoindatabase off chain as a sidechain which may be periodically oraperiodically published to a blockchain as discussed elsewhere.

In some embodiments, the trusted entity may be a digital asset exchange.A digital asset exchange, such as a digital math-based asset exchange,may allow users to sell digital assets in exchange for any other digitalassets or fiat currency and/or may allow users to sell fiat currency inexchange for any digital assets. Accordingly, an exchange may allowusers to buy digital assets in exchange for other digital assets or fiatcurrency and/or to buy fiat currency in exchange for digital assets. Inembodiments, a digital asset exchange may integrate with a foreignexchange market or platform. A digital asset exchange may be configuredas a centralized exchange or a decentralized exchange, as discussedherein.

In embodiments, the issuer of the SVCoin may be a digital assetexchange, a bank, a trust, or other trusted entity. In the context wherea digital asset exchange may act as an issuer for SVCoin, or as an agentof the issuer, a digital asset exchange computer system may maintain aledger as one or more databases associated with the SVCoin. Such adatabase may include an electronic log of all transactions, includingthe source wallet, the destination wallet, the timestamp of thetransaction, the amount of the transaction (e.g., the number of SVCoin),and/or the balance in each wallet before and/or after the transaction.In embodiments, the database may include a list of wallet addresses andbalances in each wallet of the SV Coin. In embodiments, the issuer maymaintain the database by using a smart contract in association with aContract Digital Address as part of a blockchain network, such as theEthereum Network. In embodiments, the ledger may be maintained in adatabase as a sidechain which is periodically, or aperiodically,published to a blockchain such as the Ethereum blockchain. Inembodiments, the ledger may be maintained directly on the blockchain.

FIG. 3 is a schematic diagram illustrating various potentialparticipants in a digital asset exchange, in exemplary embodiments. Theparticipants may be connected directly and/or indirectly, such asthrough a data network 15, as discussed herein. Users of a digital assetexchange may be customers of the exchange, such as digital asset buyersand/or digital asset sellers. Digital asset buyers may pay fiat (e.g.,USD, Euro, Yen, to name a few) in exchange for digital assets (e.g.,bitcoin, ether, litecoin, dogecoin, to name a few). Digital assetsellers may exchange digital assets (e.g., bitcoin, ether, litecoin,dogecoin, to name a few) for fiat (e.g., USD, Euro, Yen, to name a few).In embodiments, instead of fiat, other forms of digital assets may alsobe used.

In embodiments, users may connect to the exchange through one or moreuser electronic devices 3202 (e.g., 3202-1, 3202-2, . . . , 3202-N),such as computers, laptops, tablet computers, televisions, mobilephones, smartphones, and/or PDAs, to name a few. A user electronicdevice 3202 may access, connect to, and/or otherwise run one or moreuser digital wallets 3204. In embodiments, buyers and/or sellers mayaccess the exchange using their own electronic devices and/or through adigital asset kiosk. A digital asset enabled kiosk can receive cash,including notes, coins or other legal tender, (of one or more fiatcurrencies) from a buyer to use in buying a quantity of digital assets.A digital asset kiosk may dispense cash (of one or more fiat currencies)to a seller of digital assets. In embodiments, a digital asset kiosk mayreceive funds from and/or dispense funds to a card, such as a prepaid orreloadable card, digital asset address associated with a digital wallet,or electronic account. In embodiments, a digital wallet may be stored ona user electronic device, such as a mobile electronic device, or othercomputing device.

Users may also have user bank accounts 3208 held at one or more banks3206. In embodiments, users may be able to access their bank accountsfrom a user electronic device 3202 and/or from a digital wallet 3204 ordigital address associated therewith.

A digital asset exchange computer system 3210 can include softwarerunning on one or more processors, as discussed herein, as well ascomputer-readable memory comprising one or more database. A digitalasset exchange can include one or more exchange digital wallets 3212,e.g., digital wallet 3212-A. Exchange digital wallets may be used tostore digital assets in one or more denominations from one or moreparties to a transaction. In embodiments, exchange digital wallets maystore digital assets owned by the exchange, which may be used where anexchange is a counter-party to an exchange transaction, which can allowexchange transactions to occur even when a buyer and a seller are nototherwise both available and in agreement on transaction terms.

A digital asset exchange may have one or more bank accounts, e.g., bankaccount 3216-A, held at one or more banks 3214, such as exchange banksor exchange partner banks, which are banks associated with and/or inpartnership with the exchange. In embodiments, exchanges may accessother repositories for fiat currency. An exchange bank account may be apass-through account that receives fiat currency deposits from a digitalasset buyer and transfers the fiat currency to a digital asset seller.The exchange bank account may hold money in escrow while an exchangetransaction is pending. For example, the exchange bank account may holda digital asset buyer's fiat currency until a digital asset sellertransfers digital assets to a buyer, to an exchange, or to an authorizedthird party. Upon receipt by the appropriate recipient of the requisiteamount of digital assets, the exchange may authorize the release of thefiat currency to the digital asset seller. In embodiments, an exchangemay hold, e.g., as custodian, fiat in bank accounts and digital assetsin digital wallets at associated digital asset addresses. Inembodiments, instead of using bank accounts, other stable investmentinstruments such as money market mutual funds, treasury bills,certificates of deposits, low risk bonds, to name a few, may be used.

FIG. 4A is another schematic diagram illustrating entities associatedwith a digital asset exchange in an exemplary embodiment of the presentinvention. Each entity may operate one or more computer systems.Computer systems may be connected directly or indirectly, such asthrough a data network. Entities associated with a digital assetexchange can include the exchange, an exchange computer system 3230,customer digital asset wallets at associated digital asset addresses3222 (e.g., bitcoin wallets, ether wallets, to name a few), customerbank(s) 3224 having a customer fiat bank account(s) 3226, a digitalasset network ledger 3228 (e.g., the Bitcoin blockchain, the Ethereumblockchain, to name a few), a digital asset network (e.g., the BitcoinNetwork, the Ethereum Network, to name a few), one or more exchangecustomers using one or more customer user devices 3232, an exchangedigital asset electronic ledger 3234, one or more exchange digital assetvaults 3238, an exchange fiat electronic ledger 3236, and one or moreexchange partner banks 3242, which can have exchange pooled customerfiat accounts 3244. The exchange digital asset vaults 3238 can store aplurality of digital asset wallets, which may be pooled exchangecustomer wallets 3240 with associated digital asset addresses. Inembodiments, the exchange may have a single partner bank 3242 with apooled exchange customer fiat account 3244. Such an account may beassociated with insurance protection. In embodiments, the exchange mayhave a SVCoin system 3246. Such a system may allow users to purchaseSVCoin tokens using fiat currency and/or digital assets and/or to redeemdigital assets in the form of SVCoin tokens, and/or to redeem SVCointokens for fiat currency. SVCoin system 3246 may also be used togenerate new SVCoin tokens, and cancel redeem SVCoin tokens. SVCoinsystem 3246 is operatively connected to an SVCoin database thatmaintains a log of SVCoin tokens. In embodiments, the SVCoin databasemay be maintained as part of the digital asset network (e.g., theBitcoin Network, the Ethereum Network, to name a few).

The exchange may employ an electronic ledger system to track customerdigital assets and/or customer fiat holdings. Such a system may allowrapid electronic transactions among exchange customers and/or betweenexchange customers and the exchange itself using its own digital assetand fiat holdings or those of its sponsor or owner. In embodiments, theelectronic ledger system may facilitate rapid computer-based automatedtrading, which may comprise use by one or more computer systems of atrading API provided by the exchange. The electronic ledger system mayalso be used in conjunction with cold storage digital asset securitysystems by the exchange. Fiat (e.g., USD) and digital assets (e.g.,bitcoin or ether) can be electronically credited and/or electronicallydebited from respective (e.g., fiat and digital asset) electronicledgers. Clearing of transactions may be recorded nearly instantaneouslyon the electronic ledgers. Deposits of fiat with the exchange andwithdrawals from the exchange may be recorded on the electronic fiatledger, while deposits and withdrawals of digital assets may be recordedon the electronic digital asset ledger. Electronic ledgers may bemaintained using one or more computers operated by the exchange, itssponsor and/or agent, and stored on non-transitory computer-readablememory operatively connected to such one or more computers. Inembodiments, electronic ledgers can be in the form of a database.

A digital asset exchange computer system can include one or moresoftware modules programmed with computer-readable electronicinstructions to perform one or more operations associated with theexchange. Each module can be stored on non-transitory computer-readablememory operatively connected to such one or more computers. An exchangemay have a user on-boarding module to register users with the exchangeand/or create accounts for new and/or existing exchange users. Theexchange may employ systems and methods to ensure that the identity ofexchange customers is verified and/or the destination of fiat currencyand/or digital assets is known.

FIG. 22A is another schematic diagram illustrating entities associatedwith a digital asset exchange in an exemplary embodiment of the presentinvention. Each entity may operate one or more computer systems.Computer systems may be connected directly or indirectly, such asthrough a data network. Entities associated with a digital assetexchange can include the exchange, an exchange computer system 3230,customer digital asset wallets at associated digital asset addresses3222 (e.g., bitcoin wallets, ether wallets, to name a few), customerbank(s) 3224 having customer fiat bank account(s) 3226, a digital assetnetwork ledger 3228 (e.g., the Bitcoin blockchain, the Ethereumblockchain, to name a few), a digital asset network (e.g., the Bitcoinnetwork), one or more exchange customers using one or more customer userdevices 3232, an exchange digital asset electronic ledger 3234, one ormore exchange digital asset vaults 3238, an exchange fiat electronicledger 3236, and one or more exchange partner banks 3242, which can haveexchange pooled customer fiat accounts 3244. The exchange digital assetvaults 3238 can store a plurality of digital asset wallets, which may bepooled exchange customer wallets 3240 with associated digital assetaddresses. In embodiments, the exchange may have a single partner bank3242 with a pooled exchange customer fiat account 3244. Such an accountmay be associated with insurance protection.

The exchange may employ an electronic ledger system to track customerdigital assets and/or customer fiat holdings. Such a system may allowrapid electronic transactions among exchange customers and/or betweenexchange customers and the exchange itself using its own digital assetand fiat holdings or those of its sponsor or owner. In embodiments, theelectronic ledger system may facilitate rapid computer-based automatedtrading, which may comprise use by one or more computer systems of atrading API provided by the exchange. The electronic ledger system mayalso be used in conjunction with cold storage digital asset securitysystems by the exchange. Fiat (e.g., USD) and digital assets (e.g.,bitcoin or ether) can be electronically credited and/or electronicallydebited from respective (e.g., fiat and digital asset) electronicledgers. Clearing of transactions may be recorded nearly instantaneouslyon the electronic ledgers. Deposits of fiat with the exchange andwithdrawals from the exchange may be recorded on the electronic fiatledger, while deposits and withdrawals of digital assets may be recordedon the electronic digital asset ledger. Electronic ledgers may bemaintained using one or more computers operated by the exchange, itssponsor and/or agent, and stored on non-transitory computer-readablememory operatively connected to such one or more computers. Inembodiments, electronic ledgers can be in the form of a database.

A digital asset exchange computer system can include one or moresoftware modules programmed with computer-readable electronicinstructions to perform one or more operations associated with theexchange. Each module can be stored on non-transitory computer-readablememory operatively connected to such one or more computers. An exchangemay have a user on-boarding module to register users with the exchangeand/or create accounts for new and/or existing exchange users. Theexchange may employ systems and methods to ensure that the identity ofexchange customers is verified and/or the destination of fiat currencyand/or digital assets is known. Accordingly, the exchange may requirenew exchange customers to provide valid (e.g., complying with certaintypes, such as a driver's license or passport, or complying with certaincharacteristics) photo identification, a current address, a currentbill, such as a utility bill, biometric information (e.g., a fingerprintor hand scan), and/or bank account information. A user on-boardingmodule can include back-end computer processes to verify and store userdata as well as a front-end user interface by which a user can provideinformation to the exchange, select options, and/or receive information(e.g., through a display). The user on-boarding module can provide thefront-end interface to one or more user devices and/or platforms, suchas a computer, mobile phone (e.g., running an exchange-related mobileapplication), and/or digital asset kiosk, to name a few.

FIG. 22B shows another schematic diagram illustrating entitiesassociated with a digital asset exchange in an exemplary embodiment ofthe present invention. In addition to the participants described withrespect to FIG. 22A, a digital asset exchange may communicate with anauthenticator computer system 3246 (to authenticate users, e.g., usingmulti-factor authentication and/or comparisons to databases of flaggedusers, to name a few), an index computer system 3248 (e.g., forgenerating and/or providing a digital asset index, which may be a priceindex), and/or a market maker computer system 3250. A market maker maybe an exchange user that provides liquidity for the exchange, bypurchasing or selling digital assets.

In embodiments, an exchange computer system may calculate different feesfor a market maker. The fee calculation may vary with market conditions,such as price, digital asset supply (e.g., sell orders), and digitalasset demand (e.g., buy orders). In embodiments, transaction feescharged by an exchange may be different for purchase and saletransactions. Fees may be based upon a user's identity, a user'stransaction history, the quantity of digital assets and/or fiat currencyassociated with a user account, a rate schedule associated with aparticular account or account type (e.g., there could be different ratesfor institutional or foreign users), time of day, and/or whether theuser is operating as a market maker or a market taker for a giventransaction, to name a few.

FIGS. 5A-B are schematic diagrams of exemplary exchange computer systemsin accordance with exemplary embodiments of the present invention. FIG.5A shows hardware, data, and software modules, which may run on one ormore computers. FIG. 5B shows an exemplary distributed architecture forthe exchange computer system.

As shown in FIG. 5A, an exchange computer system 3230 can include one ormore processors 5102, a communication portal 5104 (e.g., for sendingand/or receiving data), a display device 5106, and/or an input device5108. The exchange computer system 3230 can also include non-transitorycomputer-readable memory with one or more database and data storedthereon. Data can include user identification data 5110 (e.g. know yourcustomer data obtained during the user onboarding process), user accountauthentication data 5112 (e.g., login credentials, multi-factorauthentication data, and/or anti-money laundering verifications),account activities logs 5114, electronic ledger data 5116, fiat accountbalance data 5118,digital wallet balance data 5120, and/or SVCoin data5136, to name a few. One or more software modules may be stored in thememory and running or configured to run on the one or more processors.Such modules can include a web server module 5122, authenticator module5124, risk management module 5126, matching engine module 5128,electronic ledger module 5130, digital wallet module 5132, fiat accountmodule 5134 and/or SVCoin module 5138, to name a few. The processesperformed by such modules, the data produced thereby and/or the dataaccessed thereby are described herein.

A matching engine 5128 may apply a continuous order book price timepriority matching algorithm. In embodiments, matching engine 5128 mayapply option points at low and/or high frequencies. In embodiments,other matching engines may be included, such as a block trade matchingengine (not shown), an auction matching engine (not shown), to name afew.

As shown in FIG. 5B an exchange computer system can include a web server5152, an authenticator computer system 5154, a matching engine computersystem 5156, an electronic ledger computer system 5158, a riskmanagement computer system 5160, a digital wallet computer system 5162,a fiat account computer system 5164, and/or a SV Coin Computer System5166. The exchange computer system 3230 may communicate with one or moreexternal computer systems, such as bank computer systems, index computersystems, user computer system (e.g., institutional or individual users),and/or user electronic devices, to name a few. Each computer system maycomprise one or more computers and/or one or more processors, acommunication portal, display devices, and/or input devices, to name afew.

A web server 5152 may provide display data to one or more user device102, e.g., user device 102-1. Display data may comprise website content(e.g., HTML, JavaScript, and/or other data from which a user device cangenerate and/or render one or more webpages) and/or application content,such as mobile application content, to be used in generating orproviding display content for one or more software application. Inembodiments, the web server 5152 may authenticate a user account byverifying a received username and password combination. In embodiments,other authentication processes may also be used.

An authenticator computer system 5154 may perform authentication of userlogin credentials, multi-factor authentication, and/or compare usersagainst databases, such as government databases, for compliance withanti-money laundering laws and/or regulations, to name a few.

A matching engine computer system 5156 may match buy (purchase) orderswith sell orders, receive orders, and/or update an electronic orderbook, to name a few.

An electronic ledger computer system 5158 may track and/or store accountbalances, update account balances, compute account balances, reportaccount balances, and/or place holds on account funds while transactionsare in progress (e.g., set an account hold indicator), to name a few.

A risk management computer system 5160 may perform processes to detectfraudulent transactions and/or security breaches, to name a few. Such asub-system may monitor access data describing access of the exchange(e.g., IP addresses, accounts, times of access, to name a few), monitortrading data, analyze trading data, determine patterns, determineanomalies, and/or determine violations of pre-programmed security rules,to name a few.

A digital wallet computer system 5162 may generate digital wallets withassociated digital asset addresses, generate instructions for digitalwallet key storage and/or retrieval, allocate digital assets amongdigital wallets, track digital assets, store digital asset, and/ortransfer digital assets, to name a few.

The digital wallets may include both hot wallets and cold wallets. Inembodiments, sufficient digital assets will be stored in one or more hotwallets to allow for liquidity. The amount of digital assets stored inthe one or more hot wallets may be determined based on historicalaverages of trading on the exchange. In embodiments, remaining digitalassets will preferably be held in cold wallets. A more detaileddiscussion of hot wallets and cold wallets is presented in U.S. Pat. No.9,892,460 issued Feb. 13, 2018 entitled SYSTEMS, METHODS, AND PROGRAMPRODUCTS FOR OPERATING EXCHANGE TRADED PRODUCTS HOLDING DIGITALMATH-BASED ASSETS, the entire content of which is incorporated herein.

A fiat account computer system 5164 may manage omnibus or pooledaccounts for holding customer funds. The fiat account computer systemmay process receipts of funds, e.g., from a bank, via a wire transfer,via a credit card or ACH transfer, and/or via check, to name a few.Accordingly, the fiat account computer system may communicate with oneor more external systems, such as a bank computer system. Inembodiments, the fiat account computer system may process withdrawals.In embodiments, the omnibus or pooled accounts for holding fiat aremaintained in a bank or other institution such that these accounts areeligible for insurance under the Federal Deposit Insurance Corporation(FDIC). In order to qualify for FDIC insurance, an account musttypically be associated with specific user identification information,e.g., a user name, address and social security number, by way ofexample, to name a few. Accordingly, in embodiments, fiat accounts maybe associated with individuals who are positively identified. In suchembodiments, SVCoin holders may be required to provide theidentification information discussed above prior to purchasing SVCoins.Further, the SVCoin issuer will maintain a database including thisinformation for each SVCoin holder. In embodiments, the fiat may beinvested in federally insured interest bearing bank accounts, treasurebills, bonds (such as high quality bonds), CD's, money market mutualfunds, repos or other financial instruments which offer a return andprovide sufficient stability, to name a few.

A SVCoin computer system 5166 may manage purchases of SVCoin tokensusing fiat currency and/or digital assets and/or redemption of digitalassets in the form of SVCoin tokens, and/or redemption of SVCoin tokensfor fiat currency. SVCoin computer system 5166 may also generate newSVCoin tokens and cancel redeem SVCoin tokens. SVCoin computer system5166 is operatively connected to an SVCoin database 5136 that maintainsa log of SVCoin tokens. In embodiments, the SVCoin database 5136 ismaintained by the use of smart contract code associated with a ContractAddress on the digital asset blockchain though the digital assetnetwork.

Referring to the fiat account funding process shown in FIG. 6, In stepS4720 the exchange computer system may receive fiat funding accountinformation. Such information can include a bank account number (e.g., arouting number), a bank name, an account type, and/or an accountholder's name, to name a few. In step S4722, the exchange computersystem may perform one or more validation transactions using the fiatfunding account. Such transactions may comprise small deposits into thefiat funding account. In step S4724, the exchange computer system mayreceive validation transaction information, which may include atransaction amount, date, and/or time. In step S4726, the exchangecomputer system may electronically authorize use of the fiat fundingaccount and/or request a funding transfer. Accordingly, the exchangecomputer system may provide an electronic notification, e.g., via email,via a website, and/or via a mobile phone application (e.g., via a pushnotification), to name a few, that the fiat funding account isauthorized for use with the exchange. A customer may electronicallyinitiate a transaction, e.g., through an exchange-provided userinterface or user electronic device operatively connected to theexchange or an application programming interface (API), to name a few,to transfer funds to the exchange. In step S4728, the exchange computersystem may receive an electronic notification indicating that funds werereceived, e.g., in an exchange bank account at a partner bank, from thecustomer fiat funding account. In step S4730, the exchange computersystem can update an exchange customer account with the received funds.Updating an exchange customer account can comprise electronicallyupdating a fiat electronic ledger stored one or more computer readablemedia operatively connected to the exchange computer system to reflectthe received funds and/or updating a display of the amount of funds inthe account or a data ledger on a user computer device or on a printedand/or digitally transmitted receipt provided to the user and/or a userdevice.

Referring to the digital asset account funding process shown in FIG. 6,In step S4734, the exchange computer system can receive an initialtransfer of digital assets. In step S4736, the exchange computer systemcan receive a confirmation of clearance of the digital asset transfer.In step S4738, the exchange computer system can update an exchangecustomer account with the received digital assets. Updating an exchangecustomer account can include making an electronic entry in an exchangedigital asset electronic ledger and/or providing a notification that thedigital assets are received.

FIG. 7A is an exemplary schematic diagram of an exchange, and FIG. 7B isa corresponding flow chart of a process for digital asset exchangecustomer account fiat funding via an exchange-initiated request, such asACH in accordance with exemplary embodiments of the present invention.An exchange computer system 4810 can interface with a customer digitalasset wallet 4802, a bank 4804 with a customer fiat bank account 4806,an exchange partner bank 4822 with an exchange pooled customer fiataccount 4824, a network digital asset ledger 4808, and/or a customer'suser device 4812, to name a few. In addition to the exchange computersystem 4810, the exchange can include an exchange digital assetelectronic ledger 4814, an exchange fiat electronic ledger 4816, and anexchange digital asset vault 4818 with exchange pooled customer digitalasset wallets 4820 with associated digital asset addresses. Any of theseentities or components may communicate directly and/or indirectly, e.g.,through a data network, such as the Internet. In embodiments, encryptionand/or other security protocols may be used. These entities andcomponents are further described with respect to FIG. 4A.

Referring to FIG. 7B, In step S4802 the exchange computer system canreceive, e.g., from a user device, user access credentials. In stepS4804, the exchange computer system can authenticate the user, such asby verifying the received access credentials. In step S4806, theexchange computer system may provide to a customer user device a fiatfunding interface. In step S4808, the exchange computer system mayreceive from the user device user selections for a funding source and/orfunding method. The funding source may identify a bank account or otherfiat account. The funding method may identify ACH transfer or wiretransfer, to name a few. In step S4810, the exchange computer system canreceive from the user device a funding amount value to transfer to anexchange account associated with the user. In some embodiments, stepS4808 and step S4810 may be a single step or may occur substantiallysimultaneously. Accordingly, the exchange computer system may receivefrom a user electronic device a user electronic request comprising afunding amount and a funding method. In embodiments, the funding methodmay be an ACH transfer and the request further identifies a verifieduser bank account.

In step S4812, the exchange computer system can transmit a fund transferrequest to a bank where the customer has a fiat bank account.Accordingly, the exchange computer system may transmit to an exchangepartner bank an electronic funding request comprising the funding amountand the user bank account identifier.

In step S4814, the exchange computer system can update an exchange fiatelectronic ledger with the funding transaction information. In stepS4816, the exchange computer system can receive an electronic indicationthat the funding amount was transferred from the customer's fiat bankaccount to an exchange fiat account, e.g., at a partner bank. In stepS4818, the exchange computer system can monitor the exchange fiataccount to determine the availability of funds in an exchange accountassociated with the user. In embodiments, the exchange computer systemmay generate and/or provide an electronic notification to one or moreuser devices associated with a user account that funds are available foruse on the exchange. In embodiments, the notification may indicate acurrent balance of a user account (e.g., in fiat currency and/or digitalasset quantities).

FIG. 7C is an exemplary schematic diagram of an exchange, and FIG. 7D isa corresponding flow chart of a process for digital asset exchangecustomer account fiat funding via a customer-initiated request, such asa wire transfer, in accordance with exemplary embodiments of the presentinvention. The components and entities associated with an exchange thatare shown in FIG. 7C are described with respect to FIG. 4A.

FIG. 7D is a flow chart showing an exemplary process for digital assetexchange customer account fiat funding. In step S4852, an exchangecomputer system can receive user access credentials. In step S4854, theexchange computer system can authenticate the user by verifying thereceived access credentials. Verifying the access credentials cancomprise comparing the credentials to a secure credentials database. Instep S4856, the exchange computer system can provide to a customer userdevice a fiat funding interface. In step S4858, the exchange computersystem can receive from the customer user device, user selections for afunding source and/or funding method. The funding method may be acustomer-initiated method, such as a wire transfer. In step S4860, theexchange computer system can receive a funding amount value to transferto an exchange account associated with the user. In step S4862, theexchange computer system can provide to the customer user device fundtransfer instruction, e.g., wire instructions. In step S4864, theexchange computer system may receive an electronic indication of acustomer-initiated fund transfer from a customer fiat bank account acustomer bank to an exchange fiat account at an exchange partner bankaccording to the fund transfer instructions. In embodiments, step S4864may be skipped. In step S4866, the exchange computer system may receivean indication that the funding amount was transferred from thecustomer's fiat bank account to the exchange fiat account. In stepS4868, the exchange computer system can update an exchange fiatelectronic ledger with the funding transaction information, which mayinclude an amount value, customer account ID, transaction date and/ortime, to name a few. In step S4870, the exchange computer system canmonitor the exchange fiat account to determine the availability of fundsin an exchange account associated with the user. In step S4872, theexchange computer system can provide an electronic notification to oneor more customer user devices that funds are available for use on theexchange.

FIG. 7E is a flow chart showing another exemplary process for digitalasset exchange customer account fiat funding. In step S4852′, anexchange computer system can receive user access credentials. In stepS4854′, the exchange computer system can authenticate the user byverifying the received access credentials. Verifying the accesscredentials can comprise comparing the credentials to a securecredentials database. In step S4856′, the exchange computer system canprovide to a customer user device a fiat funding interface. In stepS4857, the exchange computer system can receive a user electronicrequest comprising a funding amount and a funding method (e.g., a wiretransfer). In step S4859, the exchange computer system can provide tothe customer user device, an electronic message and/or display datacomprising wire transfer instructions. In step S4861, the exchangecomputer system can set a pending transfer indicator and/or initiate afunds receipt monitoring process. In step S4863, the exchange computersystem can receive an electronic indication that funds were received viawire transfer at an exchange fiat account at an exchange partner bank.In step S4865, the exchange computer system can verify that the receivedfunds were transferred from the authorized customer's fiat bank accountto the exchange fiat account. In step S4868′, the exchange computersystem can update an exchange fiat electronic ledger with the fundingtransaction information, which may include an amount value, customeraccount ID, transaction date and/or time, to name a few. In step S4870′,the exchange computer system can monitor the exchange fiat account todetermine the availability of funds in an exchange account associatedwith the user. In step S4872′, the exchange computer system can providean electronic notification to one or more customer user devices thatfunds are available for use on the exchange.

FIG. 8A is an exemplary schematic diagram of an exchange, and FIG. 8B isa corresponding flow chart of a process for digital asset exchangeaccount digital asset withdrawal in accordance with exemplaryembodiments of the present invention. The components and entitiesassociated with an exchange that are shown in FIG. 8A are describedherein with respect to FIG. 4A.

Referring to FIG. 8B, In step S4902, an exchange computer system canreceive user access credentials. User access credentials can include anyof a username, password, fingerprints, access card scan (e.g., swipe ofa card associated with the exchange and having a magnetic strip), and/ora pin (e.g., a number provided via SMS, other text message service, oremail for multi-factor authentication), to name a few. In step S4904,the exchange computer system can authenticate the user based upon thereceived user access credentials. In step S4906, the exchange computersystem may provide to a customer user device a withdrawal interface. Instep S4908, the exchange computer system may receive from the customeruser device user inputs comprising at least a destination digital assetaddress, typically associated with a destination digital wallet and arequested digital asset withdrawal amount value. In step S4910, theexchange computer system may verify that a digital asset accountassociated with the customer contains sufficient digital assets to coverthe requested withdrawal amount. In embodiments, such verification cancomprise reading a digital asset electronic ledger and/or determining acustomer digital asset balance, e.g., based on summing transactionsrecorded on a digital asset electronic ledger. In step S4912, theexchange computer system may update an exchange digital asset electronicledger to reflect the pending withdrawal. In embodiments, recording anentry in the electronic ledger prior to the withdrawal may be performedto prevent double spending. In other embodiments, such a step may beskipped. In step S4914, the exchange computer system may execute thewithdrawal, e.g., by broadcasting the withdrawal to a digital assetnetwork electronic ledger, e.g., the Bitcoin Blockchain, the EthereumBlockchain, to name a few. In step S4916, the destination wallet mayreceive an electronic notification of the receipt of digital assets fromthe exchange. In step S4918, the exchange computer system may monitorthe network digital asset ledger to determine whether and/or when thewithdrawal transaction is confirmed. In step S4920, the exchangecomputer system may update the digital asset electronic ledger, e.g., bydebiting the withdrawal amount from the customer's exchange account, toreflect confirmation of the withdrawal transaction. In step S4922, theexchange computer system may provide to one or more customer userdevices an electronic notification of the withdrawal. Such anotification can include at least the customer's new digital assetbalance.

A digital asset exchange can include additional systems, which mayinclude software modules, for performing various functions of theexchange. For example, an exchange can include an account managementsystem, which may comprise a user account registration system for newusers and/or an existing user account management system. The exchangecan include a trading system, which may comprise an interactive tradinginterface system, an automated trading interface system, a tradeconfirmation notification system, and/or a trade transaction feeprocessing system. A fund transfer system can include a fiat accountfunding and redemption system, a digital asset accounting funding andredemption system, and an account funding and redemption fee processingsystem. An exchange can also include a trade settlement system. Acustomer service system can include a trade dispute resolution interfacesystem and a customer account management assistance system. A customerreporting system can include a gain an loss reporting system and atransaction history system. A fraud analysis system can monitortransactions to detect fraudulent and/or unauthorized transactions. Theexchange can also include a SVCoin system, which may comprise a purchasesystem, redemption system, and a dividend payment system. In a preferredembodiment, a SVCoin system is included to allow users to purchase andredeem stable value coins using fiat currency and/or other digitalassets.

Exchange Digital Asset Storage Structure

Deposited customer fiat may be held in a pooled fiat account maintainedin a partner bank. Meanwhile, digital assets held by the exchange may bemaintained in pooled digital addresses associated with pooled digitalwallets. The exchange may store digital assets using any of the securityand/or storage systems and methods discussed herein. The exchange canemploy any combination of varying levels of secure storage for itswallets. For example, portions of digital assets held by the exchangemay be maintained in cold storage with neither the wallet's private norpublic keys ever having been exposed to a digital asset network or otherexternal network, such as the Internet. Other digital assets may bestored in air-gapped hot wallets, which may be wallets generatedoff-line with transactions generated off-line, e.g., on an isolatedcomputer, and transferred to a networked computer via a temporaryphysical connection or manual transfer. Other digital assets may bemaintained in hot wallets, e.g., to satisfy withdrawals from theexchange. The exchange may determine the amount of assets to hold in hotwallets, which may be based on historical exchange activity and/oranticipated need. A hot wallet liquidity module may analyze and predictthe amount of assets per wallet and/or during a time period required tomeet anticipated need and may also initiate transfers of assets to orfrom hot wallets to maintain desired levels. For example, a hot walletliquidity module could determine that it is desirable to maintaindigital assets in certain defined amounts (e.g., 0.5 bitcoin), and/orcertain defined fiat amounts (e.g., $100 worth of bitcoin) and/or ofcertain defined quantities sufficient to cover transactions anticipatedduring a defined period (e.g., the day's transaction). In embodiments,initiating an electronic transfer may comprise electronically generatingand providing an electronic notification to devices associated with oneor more exchange administrators of a need to transfer assets and/or anamount of assets to transfer. The exchange may designate one or morewallets for receiving incoming digital assets only. For example, theexchange may employ a single digital wallet for each receipt of digitalassets, e.g., from exchange users. The receiving wallet may be destroyedafter the received assets are transferred to one or more other wallets.

The exchange may employ any of a number of different exchange digitalwallet systems. As discussed herein, the exchange may operate a pooledor omnibus digital wallet system, e.g., as part of a centralizedexchange system. The pooled system may use an electronic ledger to trackdigital asset ownership for each exchange customer. Customers maytransfer digital assets from their own digital wallets to an exchangeaddress in order to fund their digital asset account on the exchange.The ledger can track (e.g., record) such funding events, as well aswithdrawal events. Transfers of digital assets among customers can alsobe accounted for using the ledger. With a pooled wallet system, internaltransactions on the exchange (e.g., transactions that do not entailtransferring funds to or from the exchange or exchange wallets butrather transactions between exchange wallets) can be settled withoutdelay, since the transfer can be logged through electronic ledgerupdates and does not have to otherwise be processed by a digital assetnetwork.

In another embodiment, the exchange digital wallet system may compriseexchange operated wallets for each exchange customer. These exchangeoperated wallets may be maintained in trust by the exchange for eachcustomer as associated digital asset addresses. Transactions may beprocessed by the digital asset network, e.g., the Bitcoin network, theEthereum network, to name a few. The keys to each customer wallet may beheld by the customer and/or by the exchange. Transactions may be settledvia the digital asset network in real-time (with any correspondingconfirmation period) as they occur, or transactions may be settled in abatch, which may entail broadcasting a plurality of transactions to thenetwork at a particular time or periodically throughout a day.

In another embodiment of an exchange digital wallet system, the exchangecustomers may own and/or manage their own wallets, e.g., as part of adecentralized exchange system. The exchange would not hold any customerdigital assets, and customers would hold the private keys to theirwallets with associated digital asset addresses. The exchange may matchcustomers, as described herein, so that a digital asset seller cantransfer digital assets from the seller's digital wallet to a digitalwallet corresponding to a digital asset buyer.

In embodiments, the digital wallet may be a custodial digital wallet.The custodial digital wallet may be segregated, that is, unique to aparticular customer or commingled, including digital assets of multiplecustomers. In such an embodiment, the custodian holds digital assets inthe custodial wallet for the benefit of its customers. The custodianwould hold the private key or private keys/key segments to eachcustodial wallet whether it be segregated or commingled. Transactionsmay be made between different custodial wallets or between custodialwallets and exchange customer wallets in the manner described above.

Centralized Digital Asset Exchange

In embodiments, the exchange may hold customer fiat currency and/ordigital assets in centralized, pooled accounts or wallets. The exchangemay maintain an electronic ledger to record transactions among users ofthe exchange. Separate electronic fiat account ledgers and electronicdigital asset ledgers may be maintained. Maintaining a ledger mayinvolve electronically updating the ledger to reflect pendingtransactions and/or completed transactions, which may involve debitingassets from a user's account and/or crediting assets to a user'saccount. Broadcast to a digital asset network and confirmation from adigital asset network may not be performed for transactions within theexchange, e.g., transactions between a digital asset seller sellingdigital assets that are stored by the exchange and a buyer paying withfiat currency that is held in an exchange bank account, such as a pooledaccount.

In embodiments, for both a decentralized and a centralized exchange theexchange may provide the ability for customers to purchase digitalassets from the exchange and/or sell digital assets to the exchange suchthat the exchange operator or owner is the counterparty to thetransaction. Transaction amount limits may be placed on suchtransactions and/or additional fees may be charged. In addition, inembodiments, the exchange may provide a dashboard interface for users(such as registered users) to purchase SVCoins using fiat currencyand/or digital assets and/or to redeem digital assets in the form ofSVCoins. In embodiments, the dashboard interface for the exchange mayalso allow users to redeem SVCoins for fiat currency. Since SVCoins arepegged to a fixed notional value of fiat currency, when SVCoins arepurchased an equal amount of fiat will be set aside by the exchange as areserve for when the SVCoins are redeemed. Similarly, when SVCoins areredeemed, payment for such redemption shall come from reserves set asidefor such redemption.

Exchange Operations Systems

In embodiments, a digital asset exchange may require users to opendesignated accounts associated with the user in order to participate inthe exchange. Each user may have a digital math-based asset account torecord and maintain such user's digital math-based assets and a fiataccount to record and maintain such user's fiat assets. In embodiments,the fiat assets recorded in the fiat account may be U.S. Dollars (“USD”)held in one or more omnibus bank accounts with one or more FDIC-insureddepository institutions or banks. In embodiments, a digital math-basedasset computer system of a digital asset exchange may record in anelectronic ledger information associated with a user account, such asdigital math-based asset purchase orders, digital math-based asset sellorders, digital math-based asset purchase offers, digital math-basedasset sell offers. In embodiments, digital math-based asset purchaseoffers and digital math-based asset sell offers may be converted intodigital math-based asset purchase orders and digital math-based assetsell orders, respectively, according to a user's instructions, ifcertain user-specified factors are met (e.g., digital math-based assetsare within a given price, quantity, period of time, to name a few). Inembodiments, when the digital math-based asset computer system matchesan electronic digital math-based asset purchase order with an electronicdigital math-based asset sell order, the digital math-based assetcomputer system may record the trade in an electronic ledger,effectively transferring ownership of the seller's traded digitalmath-based assets to the buyer, and ownership of the related purchaseprice in fiat currency from the buyer to the seller. In embodiments, thechanges in a user's ownership of digital math-based assets and fiatcurrency recorded in the electronic ledger are reflected in a user'sdigital math-based asset account and fiat account.

In embodiments, a digital asset exchange may accept payment methods(e.g., credit card transactions; Automated Clearing House (ACH) debits,wire transfers, digital asset transactions, to name a few) for purchasesof digital assets.

In embodiments, a digital asset exchange may hold digital math-basedassets and/or fiat currency in trust for users. Fiat currency may bemaintained in accounts with a state or federally chartered bank and maybe eligible for FDIC insurance, subject to compliance with applicablefederal regulation. In embodiments, a digital asset exchange may alsooperate a digital math-based asset storage system, in which users maydeposit digital math-based assets. In embodiments, fiat currency may betransmitted to a digital asset exchange's omnibus account. Inembodiments, the exchange may transmit fiat currency back to a user uponreceiving a request from a user.

In embodiments, a digital asset exchange may comply with relevant lawsand regulations whereby the exchange may operate in a highly regulatedbanking environment and permit necessary supervision by relevant legalauthorities. In embodiments, a digital asset exchange may comply withrules and regulations promulgated by a self-regulatory organization. Inembodiments, when a user commences an electronic digital math-basedasset purchase order to acquire digital math-based assets, the user mayeither have fiat currency in an associated user account or the buyer maysend fiat currency to the digital asset exchange's omnibus account atthe applicable bank. In embodiments, when a seller commences anelectronic digital math-based asset sell order to sell digitalmath-based assets, the seller may either have digital math-based assetsin an associated user account or may send digital math-based assets to adigital math-based asset account. In embodiments, the seller may senddigital math-based assets to one or more of digital wallets held by theexchange. In embodiments, exchange transactions may only be completedafter the digital math-based asset computer system verifies that thedigital math-based asset accounts and fiat accounts associated with theusers involved in the transaction at least equal the quantities requiredby the transaction. In embodiments, the exchange may permit tradingtwenty-four hours a day, seven days a week. In embodiments, the exchangemay shut down for scheduled and/or unscheduled maintenance periods. Inembodiments, the exchange may prohibit users from transferring fiatcurrency outside of normal business hours, in order to comply withapplicable laws and regulations. In embodiments, the exchange may allowusers to deposit and withdraw digital math-based assets outside ofnormal business hours. In embodiments, the exchange may permit users tosell digital math-based assets for fiat currency or buy digitalmath-based assets with fiat currency if the user holds sufficient fiatcurrency in its associated account prior to initiating the transaction.

Exchange-Based Stable Value Coin to Fiat Portal

In embodiments, a digital asset exchange (such as a regulated exchange)can be used to exchange SVCoin for fiat and fiat for SVCoin. SinceSVCoin is a stable value token, each token will be pegged to a stablevalue of fiat (e.g., 1 SVCoin=1 USD or 1 SVCoin=1 EUR, to name a few).In embodiments, when fiat is provided to a digital asset exchange topurchase SVCoin, a sufficient amount of fiat to cover the notional valueof the SVCoin will be set aside and held until the SVCoin is redeemed.Similarly, when SVCoin is redeemed the corresponding amount of fiatassociated with the notional value of the SVCoin will be taken from suchreserves to cover the redemption. In embodiments, each time SVCoins arepurchased, redeemed and/or traded, transaction fees may be charged bythe SVCoin issuer, and/or others involved in the transaction, such asminers on the digital asset network. Such transaction fees may becharged in fiat, SVCoin and/or other digital assets (e.g., Gas, bitcoin,ether, to name a few).

An example of a SVCoin could be Gemini Dollar. In embodiments, when fiatis provided to a digital asset exchange to purchase SVCoin, a sufficientamount of fiat to cover the notional value of the SVCoin will be setaside and held until the SVCoin is redeemed. Similarly, when SVCoin isredeemed the corresponding amount of fiat associated with the notionalvalue of the SVCoin will be taken from such reserves to cover theredemption.

In embodiments, each time SVCoins are purchased, redeemed and/or traded,transaction fees may be charged by the SVCoin issuer, and/or othersinvolved in the transaction, such as miners on the digital assetnetwork. Such transaction fees may be charged in fiat, SVCoin and/orother digital assets (e.g, Gas, bitcoin, ether, to name a few). Forexample, a purchaser may pay $1.01 USD for 1 SVcoin (that has aredemption value of $1.00 USD).

In embodiments, the SVCoin issuer may provide a discount to a purchaserof SVCoin, which may be reflected in fiat, SVCoin and/or other digitalassets (e.g., Gas, bitcoin, ether, to name a few). For example, apurchaser may pay $0.99 USD for 1 SVCoin (that has a redemption value of$1.00 USD).

In embodiments, transaction fees and/or discounts can be incurred and/orpaid at the time of transfer or at another time.

In embodiments, the SVCoin may be pegged to another stable value token.In embodiments, the SVCoin may be pegged to the value of another asset,other than fiat. In embodiments, the SVCoin may be pegged to the valueof a security, for example, a certificate of stock in a particularcompany. In embodiments, a purchaser of the SVCoin may deposit orotherwise provide to the digital asset exchange, a share of stock andwill receive an SVCoin token in return. In embodiments, the digitalasset exchange will hold the share of stock, in a custodial account, forexample, until it is redeemed. In embodiments, rather than deposit ashare of stock, a purchaser of SVCoin may deposit a sum of fiat, orother assets, sufficient to purchase a share of stock. In embodiments,the digital asset exchange may acquire a share of stock on the marketusing the assets deposited by the purchaser and then hold the share ofstock until the SVCoin is redeemed.

In embodiments, the SVCoin may be pegged to the value of a commodity. Inembodiments, a purchaser of SVCoin may deposit a sum of fiat, or otherassets, sufficient to purchase a quantity of a commodity. Inembodiments, the digital asset exchange may hold an amount of thecommodity, in a custodial account, for example, until the SVCoin isredeemed. In embodiments, the digital asset exchange may acquire thequantity of the commodity on the market using the assets deposited bythe purchaser and then hold the commodity until the SVCoin is redeemed.

In embodiments, the SVCoin may be pegged to a derivative product of astock, commodity and/or another digital asset to name a few.

In embodiments, when a user (such as a registered user of a regulateddigital asset exchange) commences a purchase order to acquire SVCoin forfiat, the user may have fiat currency in an associated user account.Alternatively, the user may send fiat currency to the exchange'saccount, such as an omnibus account, at the applicable bank. Inembodiments, when a seller sells SVCoin, the seller may have the SVCoinin an associated user account or may send SVCoin to a digital assetaccount. Specifically, the seller may send SVCoin to one or more ofdigital asset addressed, typically associated with digital wallets heldby the exchange. In embodiments, exchange transactions may only becompleted after the verification that the digital asset accounts andfiat accounts associated with the users involved in the transaction atleast equal the quantities of each required by the transaction.

In embodiments, registered users of a digital asset exchange system,such as Gemini, may purchase and/or redeem SVCoins for fiat and/or otherdigital assets though one or more digital asset dashboard interfaces. Inembodiments, the one or more digital asset dashboard interfaces mayinclude: (i) a dashboard fiat interface which allows registered users todeposit and/or withdrawal fiat with the digital asset exchange; (ii) adashboard digital asset interface which allows registered users todeposit and/or withdrawal digital assets with the digital asset exchangesystem; (iii) a dashboard SVCoin interface which allows registered usersto purchase and/or redeem SVCoins with the digital asset exchangesystem; and (iv) a dashboard Security Token interface which allowSecurity Token issuers to provide instructions to transfer SVCoins toSecurity Token holders. Each of these dashboard interfaces will now bedescribed in turn.

FIGS. 11A-1-4 illustrates an exemplary embodiment of a dashboard fiatinterface which allows registered users to deposit and/or withdraw fiatwith the digital asset exchange.

FIG. 11A-1 illustrates an exemplary embodiment of the dashboard fiatinterface as used for deposit of fiat. As illustrated, the user has theoption to make a transfer from a bank to the exchange by indicating anamount of fiat 1102 (e.g., US dollars) to be transferred from a fundingsource 1100 (e.g., a bank account).

FIG. 11A-2 illustrates an exemplary embodiment of the dashboard fiatinterface providing an option of a wire transfer. As in FIG. 11A-1, theuser indicates an amount of fiat 1102 to be transferred from a fundingsource 1100, such as a bank, to be wired to the exchange.

FIG. 11A-3 illustrates the dashboard fiat interface as used to withdrawfiat from the exchange and deposit it into a destination (e.g., a bank).In this case, the user provides a withdrawal amount of fiat 1104 and adestination 1106, such as a bank account, for the specific fiat.

Similarly, FIG. 11A-4 illustrates the dashboard fiat interface as usedto withdraw fiat via a wire transfer where the user enters thewithdrawal amount of fiat 1104 and a destination 1106, such as a bankaccount.

FIGS. 11B-1-4 illustrates an exemplary embodiment of a dashboard digitalasset interface which allows registered users to deposit and/orwithdrawal digital assets with the digital asset exchange system.

FIG. 11B-1 illustrates an exemplary embodiment of the dashboard fiatinterface as used for deposit of digital assets, specifically bitcoin inthis nonlimiting example. As illustrated, the user enters the currentaddress 1112 of the digital asset (e.g., bitcoin, ether, etc.).

FIG. 11B-2 illustrates another exemplary embodiment of the dashboardfiat interface as used for deposit of digital assets, specifically etherthis nonlimiting example. As illustrated, the user enters the currentaddress 1112 of the digital asset (ether in this example.

FIG. 11B-3 illustrates an exemplary embodiment of the dashboard fiatinterface as used for withdrawal of digital assets, specifically bitcoinin this nonlimiting example. As illustrated, the user enters thedestination address 1114 for the digital asset (bitcoin) as well asamount of digital assets 1116 to be withdrawn.

FIG. 11B-4 illustrates an exemplary embodiment of the dashboard fiatinterface as used for withdrawal of digital assets, specifically etherthis example. As illustrated, the user enters the destination address1114 of the digital asset (ether) as well as amount of digital assets1116 to be withdrawn.

FIGS. 11C-1-2 illustrates an exemplary embodiment of a dashboard SVCoininterface which allows registered users to purchase and/or redeemSVCoins with the digital asset exchange system.

FIG. 11C-1 illustrates an exemplary embodiment of the dashboard fiatinterface as used to purchase SVCoins using fiat. As illustrated, theuser may enter an amount of fiat (U.S. dollars, in this example) 1122 tobe provided from a source 1124 (e.g., a bank account) to purchase theSVCoins.

FIG. 11C-2 illustrates an exemplary embodiment of the dashboard fiatinterface as used to purchase SVCoins using digital assets (bitcoin inthis example). As illustrated, the user may enter the current address ofthe digital asset 1126.

In embodiments, a registered user may purchase SVCoins in exchange forfiat. Referring to FIG. 9A, in S9902, a registered user may log in tothe dashboard SVCoin interface, such as illustrated in FIGs.11C1-2.

In S9904, the user selects the purchase SVCoin option, and specifies theamount of SVCoins the user seeks to obtain. In embodiments, the user maybe requested to provide a digital asset address, typically associatedwith a digital wallet, such as a digital asset address associated with ablockchain digital asset, like ether. In embodiments, the amount ofSVCoins to be purchased may be specified by number of SVCoins, or by anamount of fiat. Since the SVCoins are pegged to the fiat in a stableamount (e.g., 1 SVCoin=1 USD), the system can automatically convert anddisplay the requested amount of SVCoin into fiat, or requested amount offiat into SVCoin.

In S9906, the digital asset exchange system will analyze and verify thatthe request can be properly processed. In step S9906-a, the digitalasset exchange system, as the SVCoin issuer, may verify that the userhas sufficient fiat currency maintained at the digital asset exchange tocover the transaction, including a sufficient amount of fiat to coverthe amount of SVCoin being acquired, as well as any transaction feesthat may be charged. If the user does not have sufficient fiat in thesystem, the transaction may be terminated for insufficient funds. Inembodiments, the user may be provided an opportunity to obtainsufficient funds, by, e.g., selling digital assets maintained by theuser on the digital asset exchange or by making a deposit of additionalfiat. In step S9906-b, the digital asset exchange system, may alsoverify that the digital asset address provided is a valid digital assetaddress. In step S9908-c, the digital asset exchange system, may alsopublish transactions to blockchain.

In S9908, after the digital asset exchange system has confirmed that theuser has sufficient fiat to cover the transaction, the digital assetexchange system may initiate the process of generating the requestedSVCoin. In embodiments, where SVCoins were previously generated, thenS9908 may be replaced with an alternative process S9908′ as discussedbelow.

Returning to S9908, in S9908-a, the digital asset exchange system maydebit the designated fiat funds from a fiat ledger associated with theuser account, and credit a corresponding amount of fiat to the SVCoinfiat ledger to be held in trust by the Exchange.

In S9908-b, the digital asset exchange system shall generate therequested SVCoin tokens. As part of this step, or as an additional step,the digital asset exchange system will update the SVCoin ledger toreflect the creation of the newly generated SVCoins and to indicate thedigital asset address associated with these newly generated SVCoins.

In S9908-c, the digital asset exchange system shall publish to theblockchain network (e.g., the Ethereum Network) the transaction to berecorded by the blockchain network. In embodiments, a transaction feemay be required by, e.g., a miner, to process and add the requestedtransaction on the blockchain.

As noted, when a reserve of SVCoin had been previously created but notyet distributed by the digital asset exchange system, S9908′ may beimplemented instead of S9908. At step S9908-a′, digital asset exchangecomputer system may debit the designated fiat funds from a fiat ledgerassociated with the user account, and credit a corresponding amount offiat to the SVCoin fiat ledger to be held in trust by the Exchange.

In step S9908-b′, the digital asset exchange computer system maydetermines an appropriate amount of SVCoin from the reserve to satisfythe request.

In step S9908-c′, the digital asset exchange computer system updates theSVCoin ledger to change the address associated with the portion of thereserve determined in step S9908 b′ to the address associated with theuser.

In S9910, the digital asset exchange computer system may send a messageto the registered user, and/or the designated digital asset address toreflect that the transaction was successfully processed. In embodiments,such messages may include information including: (i) digital assetaddress; (ii) the amount of tokens generated; and/or (iii) the newbalances for the digital asset address.

In embodiments, a registered user may redeem SVCoins in exchange forfiat. Referring to FIG. 9B, in S9952, a registered user may log in tothe dashboard SVCoin interface, such as illustrated in FIGS. 11C-1 and11C-2.

In S9954, the user selects the redeem SVCoin option, and specifies theamount of SVCoins the user seeks to redeem. In embodiments, the user maybe requested to provide a digital wallet address, such as a digitalwallet address associated with a blockchain digital asset, like ether.In embodiments, the amount of SVCoins may be specified by number ofSVCoins, or by an amount of fiat. Since the SVCoins are pegged to thefiat in a stable amount (e.g., 1 SVCoin=1 USD, or 100 SVCoin=1 USD, toname a few), the system can automatically convert the requested amountof SVCoin to fiat, or requested amount of fiat into SVCoin.

In S9956, the digital asset exchange system will analyze and verify thatthe request can be properly processed. In step S9956-a, the digitalasset exchange system, as the SVCoin issuer, may verify that the userhas sufficient SVCoin to cover the transaction as well as anytransaction fees that may be charged. In embodiments, the digital assetexchange system may perform verification of the SVCoin balance bychecking the token balance of the digital asset address against theSVCoin Token ledger as maintained by the digital asset blockchain. Forexample, a balance for a token issued based on the Ethereum Network maybe checked at www.etherscan.io. If the user does not have sufficientSVCoin and/or an insufficient amount for transaction fees and/orprovided an invalid digital asset address, to name a few, thetransaction may be terminated.

In embodiments, SVCoin transactions may be published and recorded in aSVCoin token side ledger that is separate from an underlying blockchain(e.g., the Ethereum Blockchain). Such a side ledger may be providedusing a sidechain, for example, a plasma chain, which is separate fromthe underlying digital asset blockchain that is maintained on thedistributed network. In embodiments, this sidechain is used to recordall transactions involving the SVCoin token and is maintained by thetoken issuer or another trusted entity on behalf of the token issuer.These transactions may then be subsequently published to the underlyingdigital asset blockchain periodically or aperiodically such that alltransactions are publicly viewable and confirmable. In embodiments, witha blockchain supporting shielded transactions, the transactions in theSVCoin token may potentially be shielded and only viewable by authorizedtoken holders. In embodiments, transactions on the sidechain may beconsolidated prior to publication on the digital asset blockchain toincrease speed of processing and reduce transaction costs.

The use of a sidechain in conjunction with a blockchain can providecertain technical advantages not otherwise available by either alone.For example, since all transactions on the sidechain are inevitablypublished to the digital asset blockchain, these transaction recordsenjoy the same benefit of immutability provided to all othertransactions on the digital asset blockchain. However, use of asidechain reduces both transaction costs and transaction times overall.Recording the transactions on the sidechain first can be accomplishedmore rapidly than transactions that are published directly to thedigital asset blockchain, which must be confirmed prior to being addedto the digital asset blockchain. In embodiments, the sidechain maysimply be a database that records all transactions such that there is noneed for miners to verify each transaction, and thus, no need to payminers for this service. In this case, transaction costs are onlyincurred for the periodic or aperiodic publication of transfers from thesidechain to the underlying digital asset blockchain.

In embodiments, the database for the SVCoin tokens may be maintained asa separate side chain from the database for each Security token. Inembodiments, one or more security tokens may be maintained in the sameside chain as the SVCoin tokens, and/or by the same trusted entitysystem as used to maintain the SVCoin token database.

In S9958, after the digital asset exchange system may confirm that theuser has sufficient SVCoin to cover the transaction, as well as anyother designated criteria, the digital asset exchange system mayinitiate the process of redeeming the designated SVCoin.

In S9958-a, the digital asset exchange system redeems the designatedSVCoin tokens, including updating the SVCoin token ledger database toreflect the debiting and cancelling of the designated tokens anddebiting the corresponding digital wallet address associated with suchredeemed SVCoin tokens. In embodiments, this process may be performed bygenerating a transaction on the digital asset exchange network from acontract digital wallet address or other authorized digital walletaddress under the relevant SVCoin smart contract programming, to be sentin S9958-c, discussed below.

In S9958-b, the digital asset exchange system credits the designatedfiat funds to a fiat ledger associated with the user account, and debita corresponding amount of fiat from the SVCoin fiat ledger being held intrust by the exchange.

In S9958-c, the digital assert exchange system publishes to theblockchain network (e.g., the Ethereum Network) the transaction to berecorded by the blockchain network. In embodiments, a transaction fee(such as Gas) may be required by, e.g., a miner, to process and add therequested transaction on the blockchain. In embodiments, the transactionfee may be specified as an amount and/or an amount limit to facilitatethe transaction being processed by a miner.

In S9960, the digital asset exchange computer system may send a messageto the registered user, and/or the designated digital asset addresses toreflect that the transaction was successfully processed. In embodiments,such messages may include information including: (i) digital assetaddress; (ii) the amount of tokens redeemed; and/or (iii) the newbalances for the digital asset address or digital wallet associatedtherewith.

Variable Permission Stable Value Tokens

FIGS. 14A-14H illustrate a method of issuing stable value digital assettokens. In embodiments, this method can control the risk associated withloss of control of an on-line key pair by using variable permissioncustodians.

In Step S1402, a first designated key pair, including a first designatedpublic key of an underlying digital asset and a corresponding firstdesignated private key, which is mathematically related, is provided.The underlying digital asset may be maintained on a distributed publictransaction ledger maintained by a plurality of geographicallydistributed computer systems in a peer-to-peer network in the form ofthe blockchain (such as the Ethereum blockchain or NEO blockchain). Thefirst designated private key may be stored on a first computer systemwhich is connected to the distributed public transaction ledger throughthe Internet (e.g., in a hot wallet).

In Step S1404, a second designated key pair, including a seconddesignated public key of the underlying digital asset and acorresponding second designated private key, which is mathematicallyrelated, is provided. The second designated private key is stored on asecond computer system which is physically separated from the firstcomputer system and is not operatively or physically connected to thedistributed public transaction ledger or the Internet (e.g., a coldwallet).

In embodiments, additional off-line designated key pairs may also beprovided.

In Step S1406, first smart contract instructions for a stable valuedigital asset token associated with a first contract address associatedwith the underlying digital asset are also provided. The smart contractinstructions are saved in the blockchain for the underlying digitalassets and include instructions for: (1) token creation; (2) tokentransfer; (3) token destruction; (4) authorization instructions for thefirst designated key pair; and (5) authorization instructions for thesecond designated key pair. In embodiments, these smart contractinstructions may be contained in one or a plurality of contractaddresses, as discussed above.

Referring to FIG. 14B, in Step S1408, a digital asset token issuersystem receives a request from a first requesting user to obtain a firstsum of stable value digital asset tokens in exchange for a second sum offiat. The first sum corresponds to the second sum based on a fixed ratioof stable value digital asset token to fiat (e.g., 1 SVCoin Token=1USD). The first requesting user is associated with an associated firstrequester key pair, including a first request public key of theunderlying asset and a corresponding first request private key, whichare mathematically related to each other.

In Step S1410, the digital asset token issuer system confirms receipt ofthe second sum of fiat.

In Step S1412, digital asset token issuer system determines whether thefirst designated key pair has authority to obtain the first sum ofstable value digital asset tokens.

Referring to FIG. 14B, in the case where the digital asset token issuersystem determines in Step S1412 that the first designated key pair hasauthority to obtain the first sum, in embodiments, in Step S1414, thesystem may perform the steps S1414 A(1)-A(5). In Step S1414A(1), thedigital asset token issuer system, generates first instructions from thefirst designated address to the contract address to obtain the first sumof stable value digital asset tokens and transfer said first sum to thefirst request public key. In Step S1414A(2), the digital asset tokenissuer system sends to the first computer, the first instructions. InStep S1414A(3), the first computer digitally signs the firstinstructions using the first designated private key to generate firstdigitally signed instructions. In Step S1414A(4), the first computersends to the digital asset token system, the first digitally signedinstructions. In Step S1414A(5), the digital asset token system sends tothe plurality of geographically distributed computer systems, the firstdigitally signed instructions.

Referring to FIG. 14C, in the case where the digital asset token issuersystem determines in Step S1412 that the first designated key pair hasauthority to obtain the first sum, in other embodiments, in Step S1414′the system may perform the following steps S1414 B(1)-B(3). In StepS1414B(1), a request is sent from the digital asset token issuer systemto the first computer, to obtain the first sum of stable value digitalasset tokens and transfer said first sum to the first request publickey. In Step S1414B(2), the first computer generates first instructionsaddressed from the first designated public key to the contract addressincluding a message to obtain the first sum of stable value digitalassets tokens and to assign the obtained first sum to the first requestpublic key, the first instructions including a digital signature basedon the first designated private key. In Step 1414B(3), the firstcomputer system sends to the plurality of geographically distributedcomputer systems, the first instructions. In embodiments, the firstcomputer may send the first instructions indirectly through anothercomputer system.

Referring to FIG. 14D, in Step S1415, the digital asset token issuersystem confirms that the first sum of stable value digital asset tokenshas been obtained and transferred to the first request public key basedon reference to the blockchain.

In embodiments, in Step S1416, the digital asset token issuer system mayreceive a second request to obtain a third sum of stable value digitalasset tokens in exchange for a fourth sum of fiat. The third sumcorresponds to the fourth sum based on the fixed ratio of stable valuedigital asset token to fiat (e.g., 1 SV Coin Token=1 USD). The secondrequest may come from a second requesting user with an associated secondrequester key pair, including a second request public key of theunderlying asset and a corresponding second request private key, whichare mathematically related.

In Step S1418, the digital asset token issuer system confirms receipt ofthe fourth sum of fiat.

In Step S1420, the digital asset token issuer system, determines whetherthe first designated key pair has authority to obtain the third sum.

In the case where the digital asset token issuer system determines inStep S1420 that the first designated key pair does not have authority toobtain the third sum, in Step S1422, the digital asset token issuersystem determines whether the second designated key pair has authorityto obtain the third sum.

Referring to FIG. 14E, in the case where the digital asset token issuersystem determines in Step S1422 that the second designated key pair hasauthority to obtain the third sum, in embodiments, the digital assettoken issuer system perform the Steps S1422A(1)-A(6). In Step S1422A(1),the digital asset token issuer system generates second instructions fromthe second designated address to the contract address to obtain thethird sum of stable value digital asset tokens and transfer said thirdsum to the second request public key. In Step S1422A(2), the digitalasset token issuer system transfers to a portable memory device, thesecond instructions. In Step S1422A(3), the second instructions aretransferred from the portable memory device to the second computer. InStep S1422A(4), the second computer digitally signs the secondinstructions using the second designated private key to generate thesecond digitally signed instructions. In Step S1422A(5), the secondcomputer transfers to a second portable memory device, the seconddigitally signed instructions. In Step S1422A(6), the second digitallysigned instructions are sent from the second portable memory device tothe plurality of geographically distributed computer systems. Inembodiments, the second digitally signed instructions may be sentindirectly through another computer system.

Referring to FIG. 14F, in the case where the digital asset token issuersystem determines in Step S1422′ that the second designated key pair hasauthority to obtain the third sum, in other embodiments, in Step S1422′,the system may perform the following steps S1422B(1)-B(3). In StepS1422B(1), a request is sent from the digital asset token issuer systemto the second computer, to obtain the third sum of stable value digitalasset tokens and transfer said third sum to the first request publickey. In Step S1422B(2), the second computer generates secondinstructions addressed from the second designated public key to thecontract address including a message to obtain the third sum of stablevalue digital assets tokens and to assign the obtained third sum to thesecond request public key, the second instructions including a digitalsignature based on the second designated private key. In Step 1422B(3),the second computer system sends to the plurality of geographicallydistributed computer systems, the second instructions. In embodiments,the second computer may send the second instructions indirectly throughanother computer system.

In Step S1424, the digital asset token issuer system confirms that thethird sum of stable value digital asset tokens have been obtained andtransferred to the second request public key based on reference to theblockchain.

In embodiments, the step of sending, from the second portable memorydevice to the plurality of geographically distributed computer systems,the second digitally signed instructions comprises the further steps oftransferring, form the second portable memory device to the digitalasset computer system, the second digitally signed instructions; andtransferring, from the digital asset computer system to the plurality ofgeographically distributed computer systems, the second digitally signedinstructions.

Referring to FIG. 14G, in embodiments, a third designated key pair,comprising a third designated public key of the underlying digital assetand a corresponding third designated private key that are mathematicallyrelated may be provided. The third designated private key may be storedon a third computer system which is physically separated from the firstcomputer system and from the second computer system and is notoperatively or physically connected to the distributed publictransaction ledger or the Internet. In such embodiments, the first smartcontract instructions further comprise authorization instructions forthe third key pair. Further, in such embodiments, in the case where thedigital asset token issuer system determines that the first designatedkey pair does not have authority to obtain the third sum, the methodfurther comprises determining, by the digital asset token issuer system,whether the third designated key pair in addition to the seconddesignated key pair have authority to obtain the third sum; and in thecase where the digital asset token issuer system determines that thethird designated key pair in addition to the second designated key pairhave authority to obtain the third sum, perform the Steps S1422C(1)-C(6)as part of step S1422. In Step S1422C(1), the digital asset token issuersystem may generate third instructions from the third designated addressto the contract address to obtain the third sum of stable value digitalasset tokens and transfer said third sum to the third request publickey. In Step S1422 C(2), the digital asset token issuer system maytransfer to a third portable memory device, the third instructions. InStep S1422C(3), the third instructions may be transferred from the thirdportable memory device to the third computer. In Step S1422C(4), thethird computer may digitally sign the third instructions using the thirddesignated private key to generate the third digitally signedinstructions. In Step S1422C(5), the third computer may transfer to afourth portable memory device, the third digitally signed instructions.In Step S1422C(6), the third digitally signed instructions may be sentfrom the fourth portable memory device to the plurality ofgeographically distributed computer systems. In embodiments, the step ofsending, from the fourth portable memory device to the plurality ofgeographically distributed computer systems, the third digitally signedinstructions comprises the further steps of (i) transferring, form thefourth portable memory device to the digital asset computer system, thethird digitally signed instructions; and (ii) transferring, from thedigital asset computer system to the plurality of geographicallydistributed computer systems, the third digitally signed instructions.In embodiments, the first portable memory device and second portablememory device are the same portable memory device. In embodiments, thefirst portable memory device and second portable memory device are thedifferent portable memory devices. In embodiments, the third portablememory device and fourth portable memory device are the same portablememory device. In embodiments, the third portable memory device andfourth portable memory device are the different portable memory devices.

Blockchain Based Dividend Using Stable Value Coin

FIG. 11D illustrates an exemplary embodiment of a dashboard SecurityToken interface which allow Security Token issuers to provideinstructions to transfer SVCoins to Security Token holders.

Referring to FIG. 12, an exemplary process flow reflecting an exemplaryembodiment is shown where a Security Token issuer initiates a transferof SVCoins to Security Token holders. It will be appreciated by thoseskilled in the art that the order of this process may be modifiedconsistent with embodiments of the present invention.

In Step S1202, the Security Token issuer (who will generally by aregistered user with the digital asset exchange) will log into thedigital asset exchange. In embodiments, the SVCoin issuer is any trustedentity, including a digital asset exchange, bank, trust or other trustedentity. In embodiments, the Security Token issuer will be an authorizeduser, or otherwise qualified with respect to the trusted entity. Inembodiments, the trusted entity may act as agent of the Security Tokenissuer to generate, distribute and maintain a ledger of SVCoins onbehalf of the Security Token issuer.

In Step S1204, the Security Token issuer system, or any trusted entitysystem acting as agent, will navigate to the dashboard Security Tokeninterface (see, e.g., FIG. 11D) to initiate a request for transfer ofSVCoins to Security Token holders. While for purposes of illustration,the request is made via the dashboard Security Token interface, those ofskill in the art will appreciate that the request may be made via APIcalls, submitted by electronic mail, and/or other electronicinteractions, consistent with embodiments of the invention. Inembodiments, the request shall identify: (i) the Security Token 1130;(ii) the total amount of SVCoins to be distributed 1132; (iii) theSecurity Token holder's digital asset addresses1134; (iii) the amount ofSVCoins to be distributed to each digital asset address1136; and/or (iv)other information sufficient to calculate or otherwise determine thisinformation. In embodiments, this information may be provided byproviding the digital asset exchange, or other trusted entity systemacting on behalf of the SVCoin issuer, with the access to the SecurityToken database, which would include the list of all current SecurityToken holders and their respective digital asset address and SecurityToken balances. In embodiments, the Security Token database may includea list of all current Security Token holders and digital asset addressesassociated with each. In such embodiments, the Security Token issuer,may still need to provide the digital asset exchange system, or othertrusted entity system, with the amount of SVCoins to be distributed,either individually and/or in total and how to prorate the distributionamong Security Token holders.

In Step S1206, the digital asset exchange system, or other trustedentity system, may analyze and verify that the request can be properlyprocessed. In step S1206-a, the digital asset exchange system, as theSVCoin issuer or on behalf of the SVCoin issuer, may verify that theuser has sufficient fiat currency maintained at the digital assetexchange to cover the transaction, including a sufficient amount of fiatto cover the amount of SVCoin being acquired, as well as any transactionfees that may be charged. If the user does not have sufficient fiat inthe system, the transaction may be terminated for insufficient funds. Inembodiments, the user may be provided an opportunity to obtainsufficient funds, by, e.g., selling digital assets maintained by theuser on the digital asset exchange or by making a deposit of additionalfiat. In step S1206-b, the digital asset exchange system, may alsoverify that the digital asset addresses, provided are each a validdigital asset addresses. To the extent any digital asset addresses arenot verified, the transaction may be rejected, and/or the digital assetexchange system may enter into a reconciliation process with theSecurity Token issuer system or trusted entity system.

At step 1206-c, the digital asset exchange system, or other trustedentity system, may determine an amount of SVCoins to be distributed toeach of the digital addresses of the Security Token holders. Inembodiments, this determination may be made based on the total number ofSecurity Token holders and the total amount of SVCoins requested by theSecurity Token issuer. In embodiments, the Security Token issuer maydesignate a specific sum of SVCoins per Security token. In embodiments,a total amount of SVCoins to be purchased may be designated in therequest of the Security Token issue with directions to equally orproportionally divide the total sum between the Security Token holders.

In S1208, after the digital asset exchange system, or other trustedentity system, has confirmed that the user has sufficient fiat to coverthe transaction, the digital asset exchange system may initiate theprocess of generating the requested SVCoin.

In S1208-a, the digital asset exchange system, or other trusted entitysystem, may debit the designated fiat funds from a fiat ledgerassociated with the Security Token issuer user account, and credit acorresponding amount of fiat to the SVCoin fiat ledger to be held intrust by the exchange. In embodiments, this fiat is held in a custodialaccount of the exchange or an agent of the exchange.

In S1208-b, the digital asset exchange system, or other trusted entitysystem, shall generate instructions to generate the requested SVCointokens, including instructions to update the SVCoin token ledgerdatabase to reflect the addition of the new tokens and the correspondingdigital asset addresses associated with such new SVCoin tokens.

In S1208-c, the digital asset exchange system, or other trusted entitysystem, shall publish to the blockchain network (e.g., the EthereumNetwork) the transaction with instructions to be recorded by theblockchain network. In embodiments, a transaction fee may be requiredby, e.g., a miner, to process and add the requested transaction on theblockchain.

In embodiments, where SVCoin tokens have already been created and aremaintained by the digital asset exchange system on reserve, S1208 may bereplaced with S1208′ as follows. In step 1208-a′, the digital assetexchange system, or other trusted entity system, may debit thedesignated fiat funds from a fiat ledger associated with the SecurityToken issuer user account, and credit a corresponding amount of fiat tothe SVCoin fiat ledger to be held in trust by the exchange, or otherwisereserved by the trusted entity.

At step S1208-b′, the digital asset exchange computer system, or othertrusted entity system may then determine a portion of the reserve fortransfer based on the requested amount of SVCoin identified by theSecurity Token issuer for transfer to the Security Token holder(s).

At step 1208-c′, the digital asset exchange computer system, or othertrusted entity system may update the SVCoin token ledger to change theaddress associated with the determined portion of the reserve SVCointokens to the address, or addresses, associated with the Security Tokenholder.

In S1210, the digital asset exchange computer system may send a messageto the Security Token issuer registered user, and/or each of thedesignated digital asset addresses to reflect that the transaction wassuccessfully processed. In embodiments, such messages may includeinformation including: (i) digital asset address; (ii) the amount oftokens generated/or determined for transfer; and/or (iii) the newbalances for the digital asset address or digital wallet associatedtherewith. In embodiments, the message may include additionalinformation related to the Security Token, including: (iv) the amount ofthe Security Token held; (v) the dividend issued; and/or (vi)instructions on how to redeem the SVCoin.

EXAMPLES

The following examples illustrate embodiments of the present invention.They are not intended to be limiting. It will be appreciated by those ofskill in the art that embodiments may be applied to other use cases notspecifically called out herein, without departing from the presentinvention.

Example 1 Real Estate Investment Trust (REIT) Token

In embodiments, shares in a real estate investment trust (“REIT Trust”)may be issued using a digital asset, such as a token on the EtherNetwork (“REIT Token”). The REIT Trust may hold income generatingproperty such as real estate which is leased. As the income generatingproperty generates fiat profits which are intended to be distributed toshareholders, a corresponding amount of fiat is to be deposited with adigital asset exchange, such as a regulated digital asset exchange likeGemini. The fiat is then converted into a SVCoin by the Exchange. TheSVCoin may then be distributed on a pro-rata basis (or as otherwiseinstructed by the REIT Trust) to REIT Token holders at the respectiveREIT Token holder's digital asset addresses associated with the EtherWallet holding the REIT Token.

REIT Token holders may then use the SVCoin as a digital asset to conductother transactions. Eventually, the SVCoin can be exchanged for fiat atthe exchange based on the notional value (e.g., 1 SVCoin=1 dollar).

Example 2 Energy Master Limited Partnership (Energy MLP) Tokens

In embodiments, shares in an Energy Master Limited Partnership (“EnergyMLP”) may be issued using a digital asset, such as a token on the EtherNetwork (“Energy MLP Token”). The Energy MLP may offer shares (otherwiseknown as “units”) in the form of a digital asset, such as Energy MLPTokens that are publicly traded and which generate dividends to theshareholders. As the dividends are distributed on a periodic basis inthe form of fiat currency, a corresponding amount of fiat is depositedwith a digital asset exchange, such as a regulated digital assetexchange like Gemini. The fiat is then converted into a SVCoin by theExchange. The SVCoin may then be distributed on a pro-rata basis (or asotherwise instructed by the Energy MLP) to Energy MLP Token holders atthe respective Energy MLP Token holder's digital asset addressesassociated with the Ether Wallet holding the Energy MLP Token.

Energy MLP Token holders may then use the SVCoin as a digital asset toconduct other transactions. Eventually, the SVCoin can be exchanged forfiat at the exchange based on the notional value (e.g., 1 SVCoin=1dollar).

Example 3 Equity Security Tokens

In embodiments, equity shares corresponding to a stock certificate in anentity may be issued using a digital asset, such as a token on the EtherNetwork (“Equity Token”). As dividends based on the Equity Token aregenerated for distribution to shareholders, a corresponding amount offiat is to be deposited with a digital asset exchange, such as aregulated digital asset exchange like Gemini. The fiat is then convertedinto a SVCoin by the Exchange. The SVCoin may then be distributed on apro-rata basis (or as otherwise instructed by the entity distributingthe shares) to Equity Token holders at the respective Equity Tokenholder's digital asset addresses associated with the Ether Walletholding the Equity Token.

Equity Token holders may then use the SVCoin as a digital asset toconduct other transactions. Eventually, the SVCoin can be exchanged forfiat at the exchange based on the notional value (e.g., 1 SVCoin=1dollar).

Example 4 Venture Capital (VC) Tokens

In embodiments, shares in a Venture Capital fund (“VC Fund”) may beissued using a digital asset, such as a token on the Ether Network (“VCToken”). As the VC Fund generates returns to be distributed to investorsin the VC Fund, a corresponding amount of fiat is to be deposited with adigital asset exchange, such as a regulated digital asset exchange likeGemini. The fiat is then converted into a SVCoin by the Exchange. TheSVCoin may then be distributed on a pro-rata basis (or as otherwiseinstructed by the VC Fund) to VC Token holders at the respective VCToken holder's digital asset addresses associated with the Ether Walletholding the VC Token.

VC Token holders may then use the SVCoin as a digital asset to conductother transactions. Eventually, the SVCoin can be exchanged for fiat atthe exchange based on the notional value (e.g., 1 SVCoin=1 dollar).

Example 5 Private Equity (PE) Tokens

In embodiments, shares in a Private Equity fund (“PE Fund”) may beissued using a digital asset, such as a token on the Ether Network (“PEToken”). As the PE Fund generates returns to be distributed to investorsin the PE Fund, a corresponding amount of fiat is to be deposited with adigital asset exchange, such as a regulated digital asset exchange likeGemini. The fiat is then converted into SVCoin by the Exchange. TheSVCoin may then be distributed on a pro-rata basis (or as otherwiseinstructed by the PE Fund) to PE Token holders at the respective PEToken holder's digital asset addresses associated with the Ether Walletholding the PE Token.

PE Token holders may then use the SVCoin as a digital asset to conductother transactions. Eventually, the SVCoin can be exchanged for fiat atthe exchange based on the notional value (e.g., 1 SVCoin=1 dollar).

Example 6 Digital Certificate of Deposit (CD) Tokens

In embodiments, digital certificate of deposits (“Digital CD”) may beissued using a digital asset, such as a token on the Ether Network (“CDToken”). As interest amounts are generated based on the terms of thecertificate of deposits, a corresponding amount of fiat is to bedeposited with a digital asset exchange, such as a regulated digitalasset exchange like Gemini. The fiat is then converted into a SVCoin bythe Exchange. Upon maturity of the Digital CD (or before maturity), theSVCoin may then be distributed on a pro-rata basis (or as otherwiseinstructed by the Digital CD issuer and/or less any premature withdrawalpenalty) to CD Token holders at the respective CD Token holder's digitalasset addresses associated with the Ether Wallet holding the CD Token.

CD Token holders may then use the SVCoin as a digital asset to conductother transactions. Eventually, the SVCoin can be exchanged for fiat atthe exchange based on the notional value (e.g., 1 SVCoin=1 dollar).

Example 7 Digital Bond Tokens

In embodiments, digital bonds may be issued using a digital asset, suchas a token on the Ether Network (“Bond Token”). As interest amounts aregenerated based on the coupon rates of the digital bonds, acorresponding amount of fiat is to be deposited with a digital assetexchange, such as a regulated digital asset exchange like Gemini. Thefiat is then converted into SVCoin by the Exchange. The SVCoin may thenbe distributed on a pro-rata basis (or as otherwise instructed by thedigital bond issuer) to Bond Token holders at the respective Bond Tokenholder's digital asset addresses associated with the Ether Walletholding the Bond Token.

Bond Token holders may then use the SVCoin as a digital asset to conductother transactions. Eventually, the SVCoin can be exchanged for fiat atthe exchange based on the notional value (e.g., 1 SVCoin=1 dollar).

Example 8 Peer-to-Peer Lending (P2P) Tokens

In embodiments, a peer-to-peer lending service (“P2P Service”) may issuea digital asset, such as a token on the Ether Network (“P2P LoanToken”). As lending amounts and interest payments are distributed,corresponding amounts of fiat is deposited with a digital assetexchange, such as a regulated digital asset exchange like Gemini. Thefiat is then converted into SVCoin by the Exchange. The SVCoin may thenbe distributed on a pro-rata basis (or as otherwise instructed by thelender/borrower) to P2P Loan Token holders at the respective P2P LoanToken holder's digital asset addresses associated with the Ether Walletholding the P2P Loan Token.

P2P Loan Token holders may then use the SVCoin as a digital asset toconduct other transactions. Eventually, the SVCoin can be exchanged forfiat at the exchange based on the notional value (e.g., 1 SVCoin=1dollar).

Example 9 Crowdfunding (CF) Tokens

In embodiments, a Crowdfunding service may issue a digital asset, suchas a token on the Ether Network (“CF Token”). As funds are collected, acorresponding amount of fiat is to be deposited with a digital assetexchange, such as a regulated digital asset exchange like Gemini. Thefiat is then converted into a SVCoin by the Exchange. The SVCoin maythen be distributed on a pro-rata basis (or as otherwise instructed bythe Crowdfunding service) to CF Token holders at the respective CF Tokenholder's digital asset addresses associated with the Ether Walletholding the CF Token.

CF Token holders may then use the SVCoin as a digital asset to conductother transactions. Eventually, the SVCoin can be exchanged for fiat atthe exchange based on the notional value (e.g., 1 SVCoin=1 dollar).

Example 10 Real Estate Crowdsourcing Tokens

In embodiments, a Real Estate Crowdsourcing services may issue a digitalasset, such as a token on the Ether Network (“RE Token”). As funds arecollected, a corresponding amount of fiat is to be deposited with adigital asset exchange, such as a regulated digital asset exchange likeGemini. The fiat is then converted into a SVCoin by the Exchange. TheSVCoin may then be distributed on a pro-rata basis (or as otherwiseinstructed by the Real Estate Crowdsourcing service) to RE Token holdersat the respective RE Token holder's digital asset addresses associatedwith the Ether Wallet holding the RE Token. RE Token holders may thenuse the SVCoin as a digital asset to conduct other transactions.Eventually, the SVCoin can be exchanged for fiat at the exchange basedon the notional value (e.g., 1 SVCoin=1 dollar).

Example 11 Artistic/Digital Rights Payment Tokens

In embodiments, tokens may be issued against an artistic work, such as asong or movie (DR Token), for example, as a token on the Ethereumnetwork. As royalties are collected for use of the song or movie, acorresponding amount of fiat may be deposited with a digital assetexchange. The fiat may be converted into SVCoin and distributed on apro-rata basis to the rights holders who are DR Token holders. Morespecifically, the SVCoin may be transferred the digital asset addressassociated with a wallet of a DR Token holder as a payment of royalties.

In embodiments, of the examples discussed above, the token holders mayinstigate payment of SVCoin by sending a request for payment. In thiscase, any transaction fees will be the responsibility of the tokenholder. In embodiments, the token issuer, or an agent thereof, mayimplement or instruct distribution of payments in which case transactionfees are the responsibility of the token issuer.

Setup and Storage of Digital Assets and/or Digital Wallets

Digital asset accounts may be securely generated, accessed, and/or used(e.g., for transactions) from a secure administrative portal. Inembodiments, the administrative portal, which may be used for keygeneration, parsing, and/or reassembly, may be a secure system fortransacting in digital math based assets comprising a first computersystem comprising one or more processors that generate one or moredigital wallets and one or more respective private keys and one or morerespective public keys, each of the one or more private keys beingsegmented into one or more private key segments; one or more writingdevices operatively connected to the one or more first computer systems,each of the one or more writing devices adapted to write at least oneprivate key segment of a corresponding one of the one or more privatekeys, along with information correlating the at least one private keysegment to one of the one or more public keys; and at least onenetworked computer comprising one or more processors that access atleast one of the digital wallets using a corresponding one of the one ormore private keys as reassembled using the corresponding private keysegments.

In embodiments, the administrative portal may further comprise a secondcomputer system comprising one or more processors for reassembling thecorresponding one of the one or more private keys based on input intothe second computer system of the corresponding private key segments. Inembodiments, the input device may be a scanner, a keyboard, atouchscreen, a mouse, a microphone, a camera, and/or a digital cardreader, to name a few.

In embodiments, the first computer system of the administrative portaland/or the second computer system may not be associated with a network.In embodiments, the first computer system of the administrative portaland the networked computer system may be a common computer system. Inembodiments, the second computer system of the administrative portal andthe networked computer system may comprise a common computer system. Infurther embodiments, the first computer system, the second computersystem, and the networked computer system may be a common computersystem.

In embodiments, referring to FIGS. 29A-29D, the administrative portalmay comprise an accounting computer 25 and a secure location 10, asdescribed herein.

Referring to the exemplary embodiment illustrated in FIG. 29A, at asecure location 10, a digital asset account holder, administrator,manager, and/or custodian may maintain at least two computers. Inembodiments, an administrator, manager, and/or custodian may becontracted to manage one or more digital asset accounts and/or overseesecurity for the accounts. In embodiments, secure location 10 may be aroom with restricted entry. In embodiments, secure location 10 may havea user entry log to provide an access record for the location.

In the exemplary embodiment depicted in FIG. 29A, at secure location 10,the first computer may be a networked computer 20, which may compriseone or more computing devices. Networked computer 20 and/or othercomputers in the system may have the ability to cycle or otherwisechange IP addresses. The second computer may be a non-networked,isolated computer 30, which may comprise one or more computing devices.In embodiments, the networked computer 20 and the isolated computer 30may be separate aspects of one computing device. For example, a harddrive partition may be used to separate the networked and non-networkedfunctions. In embodiments, the computers may comprise one or moreprocessors and/or computer readable memory. Networked computer 20 andisolated computer 30 may be located in close proximity to each other, asin the same room, or may be located in separate locations within securelocation 10. It will be appreciated by those in the art that securelocation 10 may comprise a plurality of secure locations. Inembodiments, isolated computer 30 may be located in a Faraday cage 50.The Faraday cage 50 may prevent electronic eavesdropping or interferencefrom electromagnetic waves. In alternative embodiments, the functionsascribed above to networked computer 20 and isolated computer 30 may beperformed by one or more networked and/or isolated computers at one ormore locations.

In the exemplary embodiment depicted in FIG. 29A, networked computer 20can communicate with a registry, exchange, other external entities,e.g., APs, and/or all or part of a digital asset network to send and/orreceive digital assets (e.g., to create transactions), to computebalances, and/or to transmit or otherwise broadcast signed or otherwisefinalized transactions. In embodiments, networked computer 20 may beused to distribute digital assets among one or more digital assetaccounts and/or digital wallets. The networked computer 20 may beconnected to the Internet directly (e.g., through Ethernet, Wi-Fi,Bluetooth, or any connection known in the art or hereafter developed) orindirectly (e.g., through another computer to which it is directlyconnected), or may be connected to a network other than the Internet.

In embodiments, the digital assets may be stored in one or more digitalwallets residing on one or more computing devices, such as remoteservers, personal computers, tablet devices, mobile devices, such assmart phones, or PDAs, to name a few. In the exemplary embodiment ofFIG. 29A, isolated computer 30 may be used to generate electronicwallets and/or key pairs, which may include both private and publickeys. In embodiments, keys comprise strings or alphanumeric charactersor other characters, optionally of a pre-determined length, may compriseone or more pieces of computer code, or may comprise other formats ofkeys known in the art. In embodiments, digital wallets may be created onisolated computer 30 using a “clean-boot” with a bootable CD, such as aLinux Live CD. The specific version of the operating system may bemaintained in secret to avoid security risks.

In embodiments, digital asset accounts and/or digital wallets may begenerated by an entity upon receipt of a request to transfer digitalassets to the entity and/or may be pre-generated at the time thatsecurity measures (e.g., a vault storage system) is set up, to name afew. The digital asset accounts each may be associated with uniqueprivate-public key pairs (which may include a plurality of privatekeys). In embodiments, the key pairs may be created as part of thedigital wallet creation process. In other embodiments, the key pairs maybe created before or after the creation of the one or more digitalwallets and associated with the wallets as a separate step. Inembodiments, the assets stored in a digital wallet may be accessed witha key pair, even if the original wallet is destroyed or otherwiseunavailable. In such embodiments, only the key pair need be maintainedand/or stored to retrieve the assets associated with a given digitalwallet. Accordingly, in an embodiment of the present invention, digitalwallets may be deleted or otherwise destroyed following the storage oftheir associated keys. Assets may be added to the wallet even after itsdestruction using the public key. Assets may thus be stored in a walletafter the wallet is destroyed. The wallet may be re-generated using itskeys.

In embodiments, the private key may not be used directly with or on thenetworked computer 20. In embodiments, a public key (without thecorresponding private key) may only be able to receive digital assetsfor deposit purposes. In embodiments, assets may be transferred to awallet using its public key and without the transferor knowing theprivate key. Implementation of the foregoing may require customizedsoftware, e.g., software that modifies the standard digital assetprotocols.

In embodiments, isolated computer 30 may also be used in conjunctionwith, e g., one or more printers or other writing devices, to print thekey pairs or may be used otherwise to arrange for the storage of one ormore aspects and/or portions (or segments or coded and/or encryptedsegments) of the key pairs. A printer 32 or other writing device towrite, print, or otherwise store the keys may be provided with theisolated computer 30. Such printer(s) and/or other writing device(s) maybe connected, directly and/or indirectly, to the isolated computers,such as through hardwire, wireless, or other connection. That device mayalso be located within a Faraday cage, which may be the same Faradaycage housing isolated computer 30. Storage of the keys is describedfurther below.

In embodiments, one or more isolated computers 30 can be used inconjunction with one or more printers or other writing devices to write,print or otherwise store keys. It will be appreciated by one of skill inthe art, that In embodiments, it may be desirable to limit the number orprinters or other writing devices to as few as possible to reduce riskof exposure of private keys, while In embodiments, it may be desirableto have a larger number of printers or other writing devices to handlethe volume of wallets and/or keys that need to be generated and/orwritten by the system for its operation.

Private keys may be stored in the selected format along with theircorresponding public keys. In embodiments, the private key may be storedwith a reference number which may correlate the private key to itscorresponding public key. The reference number may be (or may be storedas) a number, alphanumeric code, bar code, QR code, to name a few. Areference number master list may identify a private key, the referencenumber, and the corresponding public key. The reference number masterlist may be printed or etched on paper or some other substrate, may bestored digitally on a tape CD, DVD, computer hard drive, or othermedium, or otherwise stored in a manner known in the art. The substratesor media just described may have any suitable size, includingmicroscopic or nano scales. In embodiments, the reference number masterlist may be stored in a secure storage chamber 60 at secure location 10.Storage chamber 60 may be a lockbox, fireproof box, or other securechamber. If storage is electronic or digital, chamber 60 may protectagainst electromagnetic waves.

The private and/or public keys and/or any reference number may be storedin a variety of formats, as described herein. The keys may be dividedinto separate segments for storage. For example, a 51-character key maybe divided into three 17-character segments. The same reference numberthat correlates the private key to the public key or an additionalreference number or other identifier may indicate which key segments arepart of the same key. The reference identifier or another identifier maybe provided and stored with the one or more segments to indicate theirorder in the assembled key. A numbering schema or other convention mayalso be used to identify the order of key segments. For example, a firstsegment may begin with an “A”, a second segment may begin with a “B”,and a third segment may begin with a “C”. The key segments may be storedin one or more locations. In embodiments, the key segments may bedivided among a plurality of vaults 70, as described herein.

In embodiments, keys and/or key segments may be stored digitally and/orelectronically, e.g., on one or more computer hard drive, disk, tape,memory card, flash memory, CD-ROM, and/or DVD, to name a few. Inembodiments, the keys and/or key segments may be printed on anysubstrate, including paper, papyrus, plastic, and/or any substrate knownin the art. In embodiments, the substrate may be fireproof or fireresistant, such as a fireproof plastic. The substrate may be resistantto fluids, e.g., water resistant, or otherwise nonabsorbent. Otherprinting options may be holographic printing, three-dimensionalprinting, raised printing, such as Braille lettering, and/or invisibleink printing, such as using inks that require a special light and/ortreatment, e.g., heat and/or chemicals, for viewing. In embodiments,keys may be etched, e.g., in wood, metal, glass, plastic, or othercompositions known in the art, e.g., to produce a card. In embodiments,a magnetic encoding may be used to write to the card. In embodiments,etched or printed keys or key segments may take any shape, such ascoin-shaped tokens or rectangular blocks, to name a few. In embodiments,keys or key segments may be printed, etched, or otherwise stored asalphanumeric strings. In embodiments, keys or key segments may beprinted, etched, or otherwise stored in a form readable by programmeddevices, such as scanners. Such a form may be a QR code, a bar code,another available scanable code format and/or a proprietary code format.In embodiments, quality control operations may ensure that the keys orkey segments are printed accurately and/or are able to be read. Inembodiments, printed or etched keys or key segments may be coated toprevent reading the key without removing or otherwise altering thecoating. Such a coating may be a UV coating and/or may block X-rays orother forms of scanning or reading. The coating may be scratched off toreveal the data contained below it. The back of the substrate may alsobe coated to prevent reading through the substrate. Such a coating mayprovide an indication of whether a printed key or key segment wasaccessed or attempted to be accessed (e.g., it can be detected whethersomeone scratched the coating away).

In embodiments, security measures may be established and implemented toreduce the risk of digital wallets being compromised. Further,redundancies can be put in place to provide and/or help ensure that anyinformation necessary to access digital math-based assets in digitalwallets can be maintained and/or accessed by the account holders asappropriate, necessary, and/or desired.

Multiple private keys may be required to access a digital wallet.Multiple keys may be stored in the same manner as key segments. Inembodiments, where a second private key is required, the one or moreindividuals or systems providing the second key may be located indifferent administrative portals, different rooms, and/or differentgeographies from the one or more individuals or systems providing thefirst private key. Accordingly, a plurality of administrative portalsmay be employed by secure digital asset storage systems in accordancewith the present invention. In embodiments, a plurality of portals maybe used for retrieval of stored digital assets (e.g., by requiring asignature or private key from at least two individuals located in atleast two different portals). In embodiments, one portal may be used forre-assembling key segments and thus providing one private key, and anindividual in a second location may be required to provide a second keyor signature before a digital wallet may be accessed. The second key orsignature may be encrypted and/or segmented as described herein withrespect to a single private key.

In embodiments, a digital wallet may have more than one private key(e.g., multi-signature wallets). The plurality of private keys may bestored securely in the same manner as a single private key. Each privatekey segment pertaining to a single wallet may be stored in separatevaults, which may be electronic and/or physical vaults. By allowing formulti-signature wallets, the wallet can provide for approval/signatureauthority from more than one individual or entity as a further means tocontrol access to digital assets held in such wallet. In embodiments, asignature authority may be an automated electronic signature authority,such as a computer or computer system programmed with transactionapproval rules. The automated electronic signature authority may onlyprovide a signature when a transaction satisfies the transactionapproval rules. In other embodiments, required signature authorities maybe individuals who may be located in different administrative portals,different rooms, and/or different geographies. Accordingly, a pluralityof administrative portals may be employed by secure digital assetstorage systems in accordance with the present invention. Inembodiments, one portal may be used for re-assembling key segments andthus providing one private key, and an individual or system in a secondlocation may be required to provide a second key or signature before adigital wallet may be accessed. The second location may be a secondportal, a location in a different building, and/or a differentgeography, to name a few. The second key or signature may be encryptedand/or segmented as described herein with respect to a single privatekey.

Keys or key segments may be encrypted and/or ciphered, using one or moreciphers, as an additional security measure. The encryption and/orciphers may be applied by computers running encryption software,separate encryption devices, or by the actions of one or more persons,e.g., prior to input of the encrypted and/or ciphered data into one ormore computers. In embodiments, a key may be stored in reverse orderand/or translated (e.g., by adding 1 to each digit and/or advancing eachalphabetic character by one position in the Western alphabet, bysubstitution such as by mapping each character to a different character(e.g., A=3, 5=P, to name a few), to name a few). In embodiments, otherencryption algorithms can comprise scrambling of a sequence ofcharacters, addition of characters, and/or hashing. Other encryptiontechniques are possible. See, e.g., David Kahn, The Codebreakers: TheStory of Secret Writing, 1967, ISBN 0-684-83130-9. See also, BruceSchneier, Applied Cryptography, John Wiley & Sons, 1994, ISBN:0-471-59756-2. The encryption and/or ciphers may protect against use ofthe keys by an unauthorized entity who obtains the keys or key segmentsor copies thereof. The encoding and/or cipher may be maintained insecret and applied to decrypt or decode the keys only when keys must beaccessed and used. In embodiments, ciphering may refer to analphanumeric translation or reordering, while encryption may refer tohigher level algorithms, including hashing algorithms. In embodiments,encryption and ciphering may refer to the same processes, in which casedescriptions herein of processes involving both encryption and cipheringsteps may only entail performance of one such step so as not to berepetitive.

Following storage of the key pairs, the key pairs may be erased fromisolated computer 30. Erasure may occur using the computer operatingsystem's delete features, customized software or computer code designedto remove the data from computer memory, magnets used to physicallyerase the data from the computer's storage drives, and/or othertechniques known in the art.

A key reader 40 may be provided to assemble, read, and/or de-crypt thekeys or key segments. The key reader 40 may be contained within aFaraday cage, which may be the same Faraday cage housing isolatedcomputer 30. The key reader 40 may read keys that are printed, etched,digitally stored, or otherwise stored. Key reader 40 may be a scanner(e.g., photo scanner or bar code scanner), QR reader, laser, computerhardware, CD reader, and/or digital card reader, to name a few. Keyreader 40 may include or be operationally connected to a microscope ormagnifying device, such as for keys that are printed in microscopicsizes or other small sizes. In embodiments, key reader 40 may be pairedwith optical character recognition (“OCR”) technology to createdigitally recognized copies of keys that may have been printed, etched,or otherwise stored in a form not immediately readable by a computer.

In embodiments, key reader 40 may comprise an input device, such as akeyboard, touchscreen, mouse, and/or microphone, to name a few. An inputdevice may be used for manual entry of keys and/or key segments into oneor more computers so that the computer may further process the keysegments. Key reader 40 may be operationally connected to isolatedcomputer 30, which may be a direct connection (e.g., a USB cable,Ethernet cable, Bluetooth, or Wi-Fi, to name a few). In embodiments, keyreader 40 may be operationally connected to networked computer 20. Keyreader 40 may be operationally connected to a separate computing device.

In embodiments, reassembled keys may be input directly into a networkedcomputer 20, which may then be used to access one or more digitalwallets and/or perform one or more transactions. Key reader 40 and/orcorresponding software (e.g., running on a computer operationallyconnected to the key reader) may be programmed or otherwise designed toassemble key segments into completed keys. Key reader 40 and/orcorresponding software (e.g., running on a computer operationallyconnected to the key reader) may also correlate the private keys withtheir corresponding public keys, optionally using the reference numbermaster list. In embodiments, one or more pieces of software may be usedto retrieve, decrypt, assemble, and/or decipher keys and/or keysegments. In embodiments, such software may be run on any of one or moresecure storage system computers and/or user devices. In embodiments,multiple authority may be required to initiated a retrieval of storedprivate keys.

In embodiments, a back-up isolated computer 35 and/or a back-up keyreader 45 may be provided at secure location 10, as illustrated in FIGS.29A-29C. The back-up isolated computer 35 and key reader 45 may becontained in a back-up Faraday cage 55, which may be separate from mainFaraday cage 50. In embodiments, all or part of the administrativeportal may be duplicated and/or backed up. A duplicate administrativeportal or portion thereof may be located in a separate geographic area.A duplicate portal may serve as a disaster recovery operations portal.

In embodiments, a digital math-based asset miner, such as a bitcoinminer, may be located at or within the administrative portal. The minermay be one or more computers. In embodiments, the miner may beoperationally connected to any of the computers and/or devices at theadministrative portal described above.

In embodiments, referring to FIG. 29D, the secure location can house oneor more networked computers 20, one or more accounting computers 25, oneor more digital asset miner computers 65, one or more isolatedtransaction computers 32 operatively connected to one or more keyreaders 40, and one or more isolated wallet computers 30′, operativelyconnected to one or more writing devices 32 and, in embodiments, to oneor more key readers 40. Each isolated transaction computer 60 and/orisolated wallet computer 30′ may be isolated from each other and/orother computers electronically using a secure environment, such as aFaraday cage 50, 60.

One or more vaults 70, 70-1, 70-2, 70-3,70-N, may be used to holdassets. Vaults may be any secure storage facilities, structures, and/orsystems. For example, a vault may be a bank vault or a safety depositbox. Vaults may have appropriately controlled environments (e.g.,regulated temperature and/or humidity, to name a few) to enablelong-term storage of keys and/or key segments substrates. Vaults may beoperated by one or more entities, which may be separate entities. Inembodiments, only bonded employees may be permitted access to thevaults. Also, vaults may be located in one or more physical (e.g.,geographic) and/or digital (e.g., residing on one or more separatecomputer servers or hard drives) locations. In embodiments, vaults maybe used in conjunction with digital wallets and/or other devices and/orsystems known in the art for storing digital assets and/or data.

In the exemplary embodiments of FIGS. 29A-29D, the private keys 80 maybe divided into three segments, 80-1, 80-2, and 80-3 for storage. Eachsegment may be stored in a separate one of vaults 70-1, 70-2, and 70-3.In embodiments, two segments, four segments, five segments or anothernumber of segments can be used in accordance with embodiments thepresent invention. In embodiments, each key segment may be stored in avault operated by the same entity or by one or more different entities.

In embodiments, one or more duplicate copies of each key or key segmentmay be produced. Such duplicate copies may be stored in separate vaults,e.g., three sets of keys split into three segments may be stored in ninevaults, four sets of keys split into two segments may be stored in eightvaults, and/or the copies of key segments may be distributed among someother number of vaults, to name a few. See, e.g., FIGS. 29A-29D, to namea few. Duplicate copies may serve as a back-up in case one copy of a keyor key segment becomes corrupted, lost, or otherwise unreadable.

In embodiments, vaults may hold the keys in an organized or categorizedfashion so as to facilitate location of one or more keys or keysegments. In embodiments, a sorting reference number may be used toorganize the keys or key segments. The sorting reference number may bethe same as the reference number that correlates private and publickeys. In embodiments, etched coins or other materials or printed keys orkey segments may be stacked or otherwise arranged according to thereference number. In embodiments, an index or card catalog may describethe location of the keys. In embodiments, an automated machine may storeand retrieve key segments from storage slots, which machine may receivean input to indicate which keys or key segments to retrieve.

FIGS. 30A-30D illustrate exemplary embodiments of the present inventionwhere one or more computers 25 running accounting software to accountfor the assets and/or expenses of an account holder can be locatedeither within the secure location 10 (e.g., FIG. 30B) or outside of thesecure location 10 (e.g., FIG. 30C). In embodiments, such accountingsoftware as well as possibly other software may be stored, accessedand/or operated on one or more networked computers 20 in the securelocation 10. In embodiments, the accounting computer 25 may be the sameor different from isolated computer 30 and/or networked computer 20and/or a mining computer.

Digital Wallets

In embodiments, digital math-based assets can be stored and/ortransferred using either a website or software, such as downloadedsoftware. The website and/or downloadable software may comprise and/orprovide access to a digital wallet. Each digital wallet can have one ormore individual digital asset accounts (e.g., digital asset addresses)associated with it. Each user can have one or more digital wallets tostore digital math-based assets, digital cryptocurrency, assets and thelike and/or perform transactions involving those currencies or assets.In embodiments, service providers can provide services that are tied toa user's individual account.

Digital wallets and/or the digital asset accounts associated with and/orstored by a digital wallet may be accessed using the private key (whichmay be used in conjunction with a public key or variant thereof).Accordingly, the generation, access, use, and storage of digital assetaccounts is described herein with respect to generation, access, use,and storage of digital wallets. Such descriptions are intended to berepresentative of digital asset accounts and not exclusive thereof.

A digital wallet can be generated using a digital asset client 110(e.g., a Bitcoin client). In embodiments, a digital wallet can becreated using a key pair system, such as an asymmetric key pair like apublic key and a private key. The public key can be shared with othersto designate the address of a user's individual account and/or can beused by registries and/or others to track digital math-based assettransactions involving a digital asset account associated with thedigital wallet. Such transactions may be listed or otherwise identifiedby the digital wallet. The public key may be used to designate arecipient of a digital asset transaction. A corresponding private keycan be held by the account holder in secret to access the digital walletand perform transactions. In embodiments, a private key may be a 256-bitnumber, which can be represented by a 64-character hexadecimal privatekey and/or a 51-character base-58 private key. As discussed herein,private keys of other lengths and/or based on other numbering systemscan be used, depending upon the user's desire to maintain a certainlevel of security and convenience. Other forms of key pairs, or securitymeasures can be used consistent with embodiments of the presentinvention.

In embodiments, a digital wallet may store one or more private keys orone or more key pairs which may correspond to one or more digital assetaccounts.

In embodiments, a digital wallet may be a computer software wallet,which may be installed on a computer. The user of a computer softwarewallet may be responsible for performing backups of the wallet, e.g., toprotect against loss or destruction, particularly of the private and/orpublic key. In embodiments, a digital wallet may be a mobile wallet,which may operate on a mobile device (e.g., mobile phone, smart phone,cell phone, iPod Touch, PDA, tablet, portable computer, to name a few).In embodiments, a digital wallet may be a website wallet or a webwallet. A user of a web wallet may not be required to perform backups,as the web wallet may be responsible for storage of digital assets.Different wallet clients may be provided, which may offer differentperformance and/or features in terms of, e.g., security, backup options,connectivity to banks or digital asset exchanges, user interface, and/orspeed, to name a few.

The digital asset exchange computer system 3230 may be used to convertdigital assets into fiat or other digital assets as well as to exchangefiat for digital assets. In embodiments, a digital asset exchangecomputer system 3230 may include one or more databases that are used tostore user account authentication data, fiat account data, digitalwallet data, digital asset customer account data and transaction data,including transaction parameters and transaction instructions. A digitalwallet system is operatively connected to a decentralized digital assetnetwork that uses a decentralized electronic ledger in the form of ablockchain maintained by a plurality of physically remote computersystems to track at least one of asset ownership or transactions in adigital asset exchange system. The digital wallet system includes one ormore digital wallet modules. FIG. 23 illustrates an exemplary process bywhich the digital exchange computer system including the digital walletsystem conducts transactions. The digital wallet system receives, from auser device, transaction instructions and one or more transactionparameters associated with a transaction as indicated in step S3802. Inembodiments, the transactions parameters include on or more of (1) adigital asset strike price as a threshold for sale of a specified amountof digital assets when the price equals, rises above or falls below apredefined threshold, wherein the amount of digital assets to transactmay be specified in a different denomination; (2) digital assetdenominations; (3) digital asset amounts; (4) time periods; (5) rates ofchange; or (6) absolute amounts of change. The transaction instructionsinclude at least one of the following (1) buy; (2) sell; (3) hold; or(4) convert to a different denomination of digital asset or fiatcurrency.

In embodiments, the digital wallet system generates transaction rulesfor automatic digital asset transactions based at least the one or morereceived transaction parameters and the received transactioninstructions as indicated at step S3804. The transaction rule includecomputer code running on the one or more computers to perform atransaction when one or more specified conditions are met or not met,based on the rules.

In embodiments, the digital wallet system accesses transaction dataincluding price data associated with the specified amount of digitalassets and stores the transaction data in the one or more databases asindicated in step S3806. In an embodiment the digital wallet system mayaccess the transaction data using an application programming interfaceof an exchange agent. At step S3808, the digital wallet system evaluatesthe price data according to the transaction rules and, at step S3810,performs automated transactions when pre-defined conditions are met ornot met in accordance with the transaction rules and the price data.This evaluation may include testing the transaction data against one ormore logical conditions embodied in the transaction rules. Inembodiments, these logical conditions include determining at least oneof whether the digital asset price has reached or crossed a thresholdvalue; or whether a rate of change in price has reached or crossed athreshold value. The digital wallet system may format the transactiondata to be compatible with the digital wallet system.

In embodiments, at step S3812, the digital wallet system may generateone or more notifications to one or more user devices, with the noticesincludes at least one of a status update on transactions; notificationof at least one of incomplete, pending or failed transactions; a log ofall transactions as performed by at least one of the digital walletsystem or by a user and a log of all transaction opportunities,including transactions declined or not otherwise authorized andtransmits the one or more notifications to the user devices.

The digital asset exchange computer system also includes a fund transfersystem including a fiat account funding and redemption system, a digitalasset account funding and redemption system operatively connected to thedigital wallet system and operatively connected to the decentralizeddigital asset network and a settlement engine operatively connected tothe decentralized digital asset network and configured to carry outtransactions. The settlement engine may be configured to processspecified customer transactions to purchase or sell digital assetsaccording to a user's instructions, if certain user specified factorsare met. The user specified factors include that at least one of digitalassets are: (a) within a given price, (b) quantity, or (c) period oftime. In embodiments, the settlement engine may perform steps ofholding, by the digital asset exchange computer system, funds in escrowuntil a buyer's payment of fiat is received into a bank account;receiving, by the digital asset exchange computer system from a digitalasset buyer device, a notification of received digital assets from adigital asset seller; and providing, by the digital asset exchangecomputer system to a bank computer system associated with a digitalasset exchange bank, an instruction to release the digital asset buyer'sfunds to the digital asset seller. The settlement engine may includepre-program instructions to transfer an amount of digital assets from aseller wallet to at least one buyer wallet upon the occurrence of userspecified conditions.

In embodiments, the transaction may be at least one of formation, buyingand selling of derivative products, including call options and putoptions. In embodiments, the transaction may be at least one or more ofdigital asset lending, delayed settlements, derivative swaps, futuresand forwards.

In embodiments, the digital asset account funding and redemption systemis configured to process funding of a digital asset account held by theexchange from an exchange customer by receiving, by the digital assetexchange computer system, an initial transfer of digital assets;receiving, by the digital asset exchange computer system, a confirmationof clearance of the digital asset transfer; and updating, by the digitalasset exchange computer system, an existing customer account in the onemore or more databases with the received digital assets including makingan electronic entry in an exchange digital asset electronic ledger andproviding a notification that digital assets are received.

In embodiments, the digital asset account funding and redemption systemis configured to process withdrawing a digital asset account held by theexchange from an exchange customer. For example, the digital assetaccount funding and redemption system may provide a withdrawal interfaceto a first customer user device associated with a first customer,receive user first withdrawal data including at least a firstdestination wallet address and a first request digital wallet assetwithdrawal amount value from the first customer user device, verify thatthe first digital asset account associated with the first customercontains sufficient digital assets to cover the requested withdrawalamount by reading a digital asset electronic ledger to determine a firstdigital asset account balance; update the exchange digital assetelectronic ledger to reflect the first withdrawal data as pending,execute a first withdrawal based on the first withdrawal data bybroadcasting the first withdrawal to a digital asset network electronicledger, monitor the network digital asset ledger to determine that atransaction based on the first withdrawal is confirmed and update thedigital asset ledger to reflect confirmation of the first withdrawal. Inembodiments, the digital wallet system may request authority from a userto proceed with the automated transactions before executing theautomated transactions. In embodiments, the digital wallet system mayrequire receipt of a user's authorization before performing atransaction by at least one of telephone dialing a number and enteringspecified digits, text message, email, or via a computer application ora user's mobile wallet. In embodiments, the digital wallet system willautomatically perform the transaction if no response is received withina predetermined amount of time set by a user in advance or by default.

The digital asset exchange computer system may also include a fraudanalysis system configured to detect fraudulent and/or unauthorizedtransactions.

In embodiments, the digital math-based asset is bitcoin. In embodiments,the digital math-based asset is based on a mathematical protocol forproof of work. The mathematical protocol may be open source. Inembodiments, the mathematical protocol includes a one-way cryptographicalgorithm. In embodiments, the mathematical protocol includes asequential hard memory function. The digital math-based asset may bebased on a mathematical protocol for proof of stake and is open source.In embodiments, the digital math-based asset is based on a cryptographicmathematical protocol. The digital math-based asset may be based on amathematical protocol for a hybrid of proof of work and proof of stake.The digital math-based asset may be based on a mathematical protocol forproof of stake velocity. The mathematical protocol may rely uponownership of respective digital math-based asset as a function ofduration of ownership. The digital math-based asset may be based on amathematical protocol for proof of burn.

In embodiments, a number of digital math-based assets in thedecentralized digital assert network is limited. In embodiments, anumber of digital math-based assets in the decentralized digital assertnetwork is not limited. A specified number of digital math-based assetsin the decentralized digital asset network may be added into circulationduring a defined time period.

In embodiments, the digital wallet is activated by a private key, whichis mathematically related to a public address in a one-way function. Inembodiments, the digital wallet includes a multi-signature account whichrequires a plurality of private keys to access the digital assets heldby the multi-signature account. In embodiments, more keys are generatedfor the multi-signature account than are required to access and/or usean account.

In embodiments, an accounting computer 25 may be a hardware securitymodule, which may comprise hardware (e.g., one or more processors,computer-readable memory, communications portals, and/or input devices,to name a few) and/or software (e.g., software code designed to verifytransactions, flag potentially erroneous transactions, and/or stoppotentially erroneous or unauthorized transactions). Such a device mayverify spending transactions before the transactions are executed. Ahardware security module may flag transactions for review (e.g., byportal administrators), before the transactions may be confirmed. Ahardware security module may be an offline device, which may be given adaily account activity log (e.g., a log of exchange withdrawals,deposits, exchange transactions (e.g., purchases and sales), purchaseorder receipts, and/or sell order receipts, to name a few) to determinewhether proposed transactions, particularly spending transactions, arevalid. A protocol for identifying owners of a digital wallet may be usedto verify that spending transactions will deliver the correct amount ofassets to the correct address. In embodiments, a quorum of a specifiedsize may be required to override a hardware security module. Inembodiments, a transaction may be processed using both an isolated and anetworked computer, as discussed herein. Such a transaction may beperformed using an air-gapped digital wallet, such as described in thecontext of FIG. 36D, and isolated wallet computer 30′ within faradaycage 50 or the isolated transaction computer 32 in faraday cage 60 whichare air gapped from network computer 20. In embodiments, an unsignedtransaction may be performed on a networked computer, which may onlycontain one or more wallets capable of watching transactions and/orperforming unsigned transactions. A non-networked, isolated computer maycontain one or more complete wallets, which may be used to signtransactions. The transaction may be transferred to the isolatedcomputer for signing. Hence, an air gap or other lack of a requiredcommunication connection may exist between the isolated and networkedcomputer. In embodiments, the unsigned transaction data may betransferred manually, such as by saving the data from the networkedcomputer to a removable storage medium (e.g., a USB flash drive, CD,CD-ROM, DVD, removable hard drive, disk, memory card, to name a few),and inputting or otherwise operatively connecting the storage medium tothe isolated computer. The isolated computer may then access and signthe transaction data. The signed transaction data may then betransferred back to the networked computer using the same or differentmethod of transfer as used for the unsigned transaction data. Thenetworked computer may then access and upload, distribute, or otherwiseact on the signed transaction data to complete the transaction. Inembodiments, the isolated computer may generate and sign (e.g., with aprivate key) transaction instructions, which may then be transferred tothe networked computer for distribution to the digital asset network. Inembodiments, the networked computer and the isolated computer may beoperatively connected, e.g., using a wired connection (e.g., a USBcable, Ethernet cable, Laplink cable, to name a few) or using a wirelessconnection (e.g., Bluetooth, Wi-Fi, infrared, radio, to name a few).Such operative connection may replace the manual transfer of transactiondata between the computers, and in embodiments, security measures, suchas firewalls or automated separable physical connector devices (e.g.,controlled from the isolated computer), may be employed to protectagainst unauthorized access, particularly to the isolated computer. “Airgap, air wall or air gapping” is a network security measure employed onone or more computers to ensure that a secure computer network isphysically isolated from unsecured networks, such as the public Internetor an unsecured local area network. The name arises from the techniqueof creating a network that is physically separated (with a conceptualair gap) from all other networks. To prevent unauthorized data extrusionthrough electromagnetic or electronic exploits, there is often aspecified amount of space between the air gapped system and outsidewalls and between its wires and the wires for other technical equipment.For a system with extremely sensitive data (such as a private key of adigital asset account), as explained previously, a Faraday cage can beused to prevent electromagnetic radiation (EMR) escaping from theair-gapped equipment.

FIG. 32A illustrates an exemplary embodiment of a process for creatingdigital wallets and storing their keys. In step SO2 one or more digitalwallets may be created using one or more isolated wallet computers 30′.In step SO4, the public and private keys associated with the createddigital wallets may be obtained using one or more isolated walletcomputers 30′. In embodiments, referring to FIG. 32B, In step S05 eachprivate key may be ciphered. In step S06, each private key, which may bea ciphered private key following step S05, may be divided into segments.In step S08, one or more duplicate copies of each private key segmentmay be created. In some embodiments, the private key may be divided into2, 3, 4 or more segments. In embodiments, each private key segment maybe encrypted or otherwise encoded In step S10. In embodiments, steps S08and/or S10 may be skipped. In step S12, each private key segment may beassociated with a reference number, correlating the private key segmentto the respective public key and/or indicating the order of the privatekey segment within the complete key. In step S14, each encrypted privatekey segment may be converted to a storable medium, such as by printingeach private key segment on paper. In step S16, the private key segmentas converted in the storable medium (e.g., printed) is verified toconfirm it was properly and retrievable stored. In embodiments, thisstep may be skipped. In step S18, each private key segment is storedalong with its reference number at one or more secure locations. In stepS20, each digital wallet is deleted, leaving the stored keys as a meansto regenerate the wallets.

FIG. 33A is a flow chart of a process for generating digital assetaccounts and securely storing the keys corresponding to each account. Inembodiments, the process may be performed using one or more isolatedcomputers not connected to any external data networks. The isolatedcomputer may comprise a clean copy of an operating system (e.g., a cleanboot) stored in computer-readable memory and running on one or moreprocessors.

In step S6002, a computer system comprising one or more computers may beused to generate one or more digital asset accounts capable of holdingone or more digital math-based assets. In embodiments, such accounts maybe associated with digital asset ownership and/or possession withoutphysically holding a digital asset in any location. A digital assetsoftware client, which may comprise part of a digital wallet or may beaccessed using a digital wallet, may be used to generate the digitalasset accounts.

In step S6004, the computer system may be used to obtain one or moreprivate keys corresponding to the one or more digital asset accounts. Inembodiments, the private keys may be generated as part of the digitalasset account creation process.

In step S6006, the computer system may be used to divide each of the oneor more private keys into a plurality of private key segments. Inembodiments, such as with a multi-signature wallet, at least one privatekey for each digital asset account may be divided into private keysegments.

In step S6008, the one or more computers may be used to encrypt each ofthe plurality of private key segments. Encryption can comprise any ofthe techniques described herein, such as character substitution,scrambling, mapping, and/or hashing, to name a few. The computer systemcan apply one or more algorithms to perform the encryption. Symmetricand or asymmetric encryption algorithms may be applied.

In step S6010, the one or more computers may be used to generate and/orassociate each of the plurality of private key segments with arespective reference identifier. A reference identifier may be a number,alphanumeric sequence, or other unique sequence that can be used toidentify key segments, which may be used for storage and/or retrieval ofkey segments. The reference identifier for each key segment may bestored on a reference identifier master list, which may be storedelectronically and/or on a physical substrate. The reference identifiermaster list may associate with each other the reference identifiers forkey segments corresponding to the same key, and/or may also associate adigital asset account identifier (e.g., a public key or public address)with the key segments.

In step S6012, the one or more computers may be used to create one ormore cards for each of the encrypted plurality of private key segments.Each card may have fixed thereon one of the encrypted plurality ofprivate key segments along with the respective associated referenceidentifier. The cards may be paper, such as index cards, 8½ in.×11 in.sheets of paper, or other paper products. In other embodiments, thecards may include plastic or metal. The cards may be laminated. Awriting device may fix the key segments and reference identifiers to thecards by techniques such as printing, etching, and/or magneticallyencoding, to name a few. A scanable code, such as a bar code or QR code,may be used to write the keys to the cards.

In embodiments, collated sets of cards may be produced for a pluralityof digital asset accounts. Each set may contain only one card perprivate key such that the private key segments for a single private keyare divided among different sets of cards.

In embodiments, following creation of the one or more cards, qualitycontrol steps can be performed. A reading device may be used to readeach of the cards to ensure readability.

In step S6014, the one or more computers may be used to track storage ofeach of the one or more cards in one or more vaults. Vaults may begeographically remote. Vaults can include bank vaults and/or preciousmetal vaults. In embodiments, a main set of vaults and one or more setsof backup vaults may be used. A main set of vaults can be located in ageographically proximate area, such as a metropolitan area of a city,while backup sets of vaults may be located in geographically remoteareas. The backup vaults may contain duplicate copies of the cards.Vault locations for each card or set of cards may be included on thereference identifier master list.

In embodiments, the process can further include receiving at thecomputer system a quantity of digital math-based assets, and storingthose digital assets in the one or more securely stored digital assetaccounts. In embodiments, storing the digital asset can comprisetransferring the digital assets into accounts with securely storedprivate keys. Accordingly, storing can comprise generating electronictransfer instructions for an electronic transfer of the quantity ofdigital math-based assets to the one or more digital asset accounts andbroadcasting the electronic transfer instructions to a decentralizedelectronic ledger maintained by a plurality of physically remotecomputer systems.

FIG. 33B is a flow chart of another exemplary process for generatingdigital asset accounts and securely storing the keys corresponding toeach account.

In step S6022, a computer system comprising one or more computers may beused to generate one or more digital asset accounts capable of holdingone or more digital math-based assets, as described with respect to stepS6002 of FIG. 6A.

In step S6024, the computer system may be used to obtain one or moreprivate keys corresponding to the one or more digital asset accounts, asdescribed with respect to step S6004 of FIG. 6A.

In step S6026, the computer system may be used to encrypt each of theone or more private keys.

After encryption, In step S6028, the computer system may be used todivide each of the encrypted private keys into a plurality of keysegments.

In step S6030, the one or more computers may be used to generate and/orassociate each of the plurality of private key segments with arespective reference identifier.

In step S6032, the one or more computers may be used to create one ormore cards for each of the plurality of private key segments.

In step S6034, the one or more computers may be used to track storage ofeach of the one or more cards in one or more vaults.

FIG. 33C is a flow chart of another exemplary process for generatingdigital asset accounts and securely storing the keys corresponding toeach account. The exemplary process may generate and store keys for, amulti-signature digital asset account, where at least one of the privatekeys is divided into a plurality of key segments.

In step S6042, a computer system comprising one or more computers may beused to generate one or more digital asset accounts capable of holdingone or more digital math-based assets.

In step S6044, the computer system may be used to obtain a firstplurality of private keys corresponding to each of the one or moredigital asset accounts. Each first plurality of private keys cancomprise the private keys of a multi-signature account.

In step 6046, the computer system may be used to divide a first privatekey of the first plurality of private keys into a second plurality offirst private key segments. For a multi-signature digital asset accountat least one of the private keys may be divided into private keysegments.

In step S6048, the computer system may be used to encrypt each of thesecond plurality of first private key segments. In embodiments, thesecond key may be encrypted.

In step S6050, the computer system may be used to generate and/orassociate each of the second plurality of first private key segmentswith a respective reference identifier.

In step S6052, the computer system may be used to create one or morecards for each of the encrypted second plurality of first private keysegments wherein each of the one or more cards has fixed thereon one ofthe encrypted second plurality of first private key segments along withthe respective associated reference identifier. In embodiments, thesecond key may be written, e.g. using the writing device, to one or morephysical substrates, such as paper, plastic, and/or metal. In otherembodiments, the second key may be stored electronically.

In step S6054, the computer system may be used to track storage of eachof the cards in one or more vaults, as well as to track storage of thesecond private key. A reference identifier master list may identify thestorage locations of each key and key segment.

FIG. 33D is a flow chart of an exemplary process for securely generatingdigital asset accounts and storing associated keys using a secureportal.

In step S6062, an electronic isolation chamber may be providedcontaining one or more writing devices (e.g., printers, engravers,magnetic card encoders, to name a few), one or more reading devices(e.g., scanners, bar code scanners, QR readers, magnetic card readers,to name a few), and an isolated computer operatively connected to theone or more writing devices but not directly connected to an externaldata network and comprising one or more processors and computer-readablememory.

In step S6064, the isolated computer may be used to generate a firstplurality of digital asset accounts capable of holding one or moredigital math-based assets. In embodiments, the first plurality ofdigital asset accounts may comprise multi-signature digital assetaccounts.

In step S6066, the isolated computer may be used to obtain one or moreprivate keys and a digital asset account identifier corresponding toeach of the first plurality of digital asset accounts.

In step S6068, the isolated computer may be used to associate each ofthe one or more digital asset accounts with a respective referenceidentifier. The reference identifier may comprise an alphanumericsequence. In embodiments, respective reference identifiers may beassociated with one or more keys or key segments corresponding to therespective digital asset accounts.

In step S6070, the isolated computer may be used to divide at least oneof the one or more private keys corresponding to each of the firstplurality of digital asset accounts into a second plurality of privatekey segments. In embodiments, each private key segment may be requiredto regenerate the respective private key. In embodiments, a subset ofthe second plurality of private key segments (e.g., 3 of 5 keys) couldbe sufficient to regenerate the respective private key.

In step S6072, the isolated computer may transmit to the one or morewriting devices, electronic writing instructions for writing each of thesecond plurality of private key segments and the respective referenceidentifier on a respective card to generate a third plurality ofcollated sets of cards wherein each of the collated sets of cardscomprises cards corresponding to different private keys. In embodiments,the third plurality of collated sets can include one or more duplicatesets for each of the collated sets of cards. In embodiments, theisolated computer may be used to generate the electronic writinginstructions prior to transmitting them to the one or more writingdevices.

In step S6074, the one or more writing devices may be used to write eachrespective private key segment of the second plurality of private keysegments and the respective reference identifier on a respective cardaccording to the electronic writing instructions. In embodiments, stepS6074 can comprise printing and/or etching each respective private keysegment of the plurality of private key segments and the respectivereference identifier on respective separate cards. In embodiments, eachrespective private key segment of the plurality of private key segmentsmay be magnetically encoded on respective separate cards. The respectivereference identifiers may be printed on the respective cards, e.g., tobe readable without a magnetic card reader. Each respective private keysegment of the second plurality of private key segments may be written,e.g., printed, as a scanable code, such as a bar code and/or a QR code.

In step S6076, the isolated computer may be used to write each of thedigital asset account identifiers along with the corresponding referenceidentifier. In embodiments, step S6076 can further comprise the steps oftransmitting, from the isolated computer to the one or more writingdevices, second electronic writing instructions for writing each of thedigital asset account identifiers along with the corresponding referenceidentifier, and writing, using the one or more writing devices, each ofthe digital asset account identifiers along with the correspondingreference identifier according to the second writing instructions. Inembodiments, writing according to the second writing instructions cancomprise writing to an electronic storage medium, such as a flash drive,hard drive, and/or disc. In embodiments, the electronic storage mediumcould include a hardware storage module (“HSM”). In embodiments, writingaccording to the second writing instructions can comprise writing to aphysical storage medium, such as paper.

In step S6078, the one or more reading devices may be used to read eachof the cards to ensure readability. In embodiments, step S6078 may beperformed after step S6076. In embodiments, step S6078 may be performedbefore step S6076.

In embodiments, the process illustrated by FIG. 33D can further comprisethe step of writing, using the isolated computer, the respective digitalasset account identifiers to a removable electronic storage medium,e.g., for transfer to an accounting computer.

In embodiments, the process can further comprise the step of destroyingthe isolated computer, the one or more writing devices, and the one ormore reading devices, or destroying any one of those devices.

In embodiments, the method can further comprise the step of encrypting,using the isolated computer, each of the second plurality of private keysegments. In embodiments, encryption techniques can includesymmetric-key encryption, asymmetric-key encryption, scrambling,substitution, hashing, or adding characters.

In embodiments, the method can further comprise the step of tracking,using the isolated computer, storage of each of the third plurality ofcollated sets of cards. In embodiments, each of the third plurality ofcollated sets of cards may be stored in a vault. In embodiments, eachcollated set of cards may be stored in a separate vault.

FIGS. 29B and 29C illustrate exemplary embodiments of the presentinvention where one or more computers 25 running accounting software toaccount for the assets and/or expenses of an account holder can belocated either within the secure location 10 (e.g., FIG. 29B) or outsideof the secure location 10 (e.g., FIG. 29C). In embodiments, suchaccounting software as well as possibly other software may be stored,accessed and/or operated on one or more networked computers 20 in thesecure location 10. In embodiments, the accounting computer 25 may bethe same or different from isolated computer 30 and/or networkedcomputer 20 and/or a mining computer.

In embodiments, an accounting computer 25 may be a hardware securitymodule, which may comprise hardware (e.g., one or more processors,computer-readable memory, communications portals, and/or input devices,to name a few) and/or software (e.g., software code designed to verifytransactions, flag potentially erroneous transactions, and/or stoppotentially erroneous or unauthorized transactions). Such a device mayverify spending transactions before the transactions are executed. Ahardware security module may flag transactions for review (e.g., byportal administrators), before the transactions may be confirmed. Ahardware security module may be an offline device, which may be given adaily account activity log (e.g., a log of ETP redemptions and/orcreations) to determine whether proposed transactions, particularlyspending transactions, are valid. A protocol for identifying owners of adigital wallet may be used to verify that spending transactions willdeliver the correct amount of assets to the correct address. Inembodiments, a quorum of a specified size may be required to override ahardware security module. In embodiments, a transaction may be processedusing both an isolated and a networked computer, as discussed herein.Such a transaction may be performed using an air-gapped digital wallet,such as described in the context of FIG. 29D, and isolated walletcomputer 30′ within faraday cage 50 or the isolated transaction computer32 in faraday cage 60 which are air gapped from network computer 20. Inembodiments, an unsigned transaction may be performed on a networkedcomputer, which may only contain one or more wallets capable of watchingtransactions and/or performing unsigned transactions. A non-networked,isolated computer may contain one or more complete wallets, which may beused to sign transactions. The transaction may be transferred to theisolated computer for signing. Hence, an air gap or other lack of arequired communication connection may exist between the isolated andnetworked computer. In embodiments, the unsigned transaction data may betransferred manually, such as by saving the data from the networkedcomputer to a removable storage medium (e.g., a USB flash drive, CD,CD-ROM, DVD, removable hard drive, disk, memory card, to name a few),and inputting or otherwise operatively connecting the storage medium tothe isolated computer. The isolated computer may then access and signthe transaction data. The signed transaction data may then betransferred back to the networked computer using the same or differentmethod of transfer as used for the unsigned transaction data. Thenetworked computer may then access and upload, distribute, or otherwiseact on the signed transaction data to complete the transaction. Inembodiments, the isolated computer may generate and sign (e.g., with aprivate key) transaction instructions, which may then be transferred tothe networked computer for distribution to the digital asset network. Inembodiments, the networked computer and the isolated computer may beoperatively connected, e.g., using a wired connection (e.g., a USBcable, Ethernet cable, Laplink cable, to name a few) or using a wirelessconnection (e.g., Bluetooth, Wi-Fi, infrared, radio, to name a few).Such operative connection may replace the manual transfer of transactiondata between the computers, and in embodiments, security measures, suchas firewalls or automated separable physical connector devices (e.g.,controlled from the isolated computer), may be employed to protectagainst unauthorized access, particularly to the isolated computer.

FIG. 34 is a flow chart of a process for retrieving securely storedprivate keys in accordance with exemplary embodiments of the presentinvention.

In exemplary embodiments, in step S702, a computer system comprising oneor more computers may be used to determine one or more digital assetaccount identifiers corresponding to one or more digital asset accountscapable of holding one or more digital math-based assets.

In step S704, the computer system may be used to access key storageinformation associated with each of the one or more digital assetaccount identifiers. In embodiments, the key storage information maycomprise a reference identifier associated with one or more storedprivate key segments.

In step 706, the computer system may be used to determine, based uponthe key storage information, storage locations corresponding to each ofa plurality of private key segments corresponding to each of the one ormore digital asset accounts.

In step 708, retrieval instructions for retrieving each of the pluralityof private key segments may be issued or caused to be issued.

In step 710, each of the plurality of private key segments may bereceived at the computer system.

In step 712, the computer system may be used to decrypt each of theplurality of private key segments.

In step 714, the computer system may be used to assemble each of theplurality of private key segments into one or more private keys.

In embodiments, the process depicted in FIG. 34 may further comprise thestep of accessing, using the computer system, the one or more digitalasset accounts associated with the one or more private keys. In furtherembodiments, the process depicted in FIG. 34 may further comprise thesteps of accessing, using an isolated computer of the computer system,wherein the isolated computer is not directly connected to an externaldata network, the one or more digital asset accounts associated with theone or more private keys; generating, using the isolated computer,transaction instructions comprising one or more transfers from the oneor more digital asset accounts; transferring the transactioninstructions to a networked computer of the computer system; andbroadcasting, using the networked computer, the transaction instructionsto a decentralized electronic ledger maintained by a plurality ofphysically remote computer systems.

FIG. 35 describes an exemplary method of performing secure transactions.In step S702, a digital wallet may be created on an isolated computer.In step S704, a watching copy of the digital wallet, which may notinclude any private keys, may be created on the isolated computer. Instep S706, the watching copy of the digital wallet may be transferredfrom the isolated computer to a networked computer. In step S708, anunsigned transaction may be created using the watching copy of thewallet on the networked computer. In step S710, data associated with theunsigned transaction may be transferred from the networked computer tothe isolated computer. In step S712, the unsigned transaction data maybe signed using the digital wallet on the isolated computer. In stepS714, the signed transaction data may be transferred from the isolatedcomputer to the networked computer. In step S716, the signed transactiondata may be broadcast, using the watching copy of the wallet on thenetworked computer, to a digital asset network. In embodiments, thebroadcast of a signed transaction may complete a transaction and/orinitiate a verification process that may be performed by the network.

In embodiments, processes for generating digital asset accounts and/orstoring associated keys may be performed by a secure system, e.g., anadministrative portal. The system can comprise an electronic isolationchamber, such as a Faraday cage. The system can further comprise one ormore isolated computers within the electronic isolation chamber andcomprising one or more processors and computer-readable memoryoperatively connected to the one or more processors and having storedthereon instructions for carrying out the steps of (i) generating, usingthe one or more isolated computers, one or more digital asset accountscapable of holding one or more digital math-based assets; (ii)obtaining, using the one or more isolated computers, one or more privatekeys corresponding to the one or more digital asset accounts; (iii)dividing, using the one or more isolated computers, at least one of theone or more private keys for each digital asset account into a pluralityof private key segments, wherein each private key segment will bestored; (iv) associating, using the one or more isolated computers, eachof the plurality of private key segments with a respective referenceidentifier; and (v) transmitting, from the one or more isolatedcomputers to one or more writing devices operatively connected to theone or more isolated computers, electronic writing instructions forwriting a plurality of cards, collated into a plurality of sets havingonly one private key segment per digital asset account, and each cardcontaining one of the plurality of private key segments along with therespective associated reference identifier. The system can furthercomprise one or more writing devices located within the electronicisolation chamber and configured to perform the electronic writinginstructions, including collating the plurality of cards into theplurality of sets. The system can also comprise one or more readingdevices located within the electronic isolation chamber and configuredto read the plurality of private key segments along with the respectiveassociated reference identifier from the one or more cards. The readingdevices may be used for quality control, to ensure that the cards arereadable.

Cold Storage

In embodiments, a digital asset account holder may operate one or morecomputers to manage, process, and/or store the transactions and/ordigital assets. In embodiments, a portion, consisting of some or all, ofthe digital assets may be stored in cold storage, which involves nooutside connections. Cold storage may be a bank vault, a precious metalvault, a lockbox, or some other secure room or area. There may be nocommunication channels connecting to the cold storage area. Inembodiments, electronic vaults may be used. Electronic vaults maycomprise cloud storage, one or more hard drives, flash drives, memorycards or like storage technology, to name a few. Electronic vaults mayhold one or more keys and/or key segments, which may be encrypted and/orencoded as described herein.

In embodiments, the cold storage may comprise a divided storage system.In a divided storage system, components or portions of components may bestored at multiple locations. Components may be at least digitalwallets, public and/or private keys, or assets.

FIG. 31A is a schematic diagram of a cold storage vault system inaccordance with exemplary embodiments of the present invention. Inembodiments, each private key to be stored in vaults 70 for cold storagemay be divided into one or more segments 80. In embodiments, eachsegment can be stored in a separate vault 70. In this manner, the riskof each of the segments 80 being reassembled into a complete key may bereduced due to the segregation of each piece of each key. Each vault maythen be located at different locations, e.g., Locations A, B, and C. Inembodiments, each vault (e.g., 70-Aa, 70-A2, 70-A3) may be located atdifferent locations in the same general vicinity (e.g., the generalvicinity of Location A, which may be New York City). Each vault may havea user entry log to provide a record of access to the vault and/or mayemploy security measures to ensure only authorized access.

Duplicate sets of the segmented private keys may then be made and storedin separate vaults (e.g., one duplicate copy divided between Vaults70-B1, 70-B2, and 70-B3, and another duplicate copy divide betweenVaults 70-C1, 70-C2, and 70-C3). Each set of segmented keys 80 may belocated in the same general vicinity (e.g., Location B for Vaults 70-B1,70-B2, and 70-B3 and Location C for Vaults 70-C1, 70-C2, and 70-C3),with each general vicinity being different from other general vicinities(e.g., Location B may be Philadelphia, Pennsylvania and Location C maybe Indianapolis, Indiana). Locations may include domestic and/orinternational locations. Locations can be selected based on at least oneor more of the following parameters: ease of access, level of security,diversity of geographic risk, diversity of security/terror risk,diversity of available security measures, location of suitable vaults inexistence (e.g., custodian vaults for a trust associated with an ETP),space available at vaults, jurisdictional concerns, to name a few. Inembodiments, three geographic locations can be used wherein Location Ais within a short intraday time of transit (e.g., 1 hour), Location B iswithin a longer intraday time of transit (e.g., 3-4 hours), and LocationC is within one or more day times of transit (e.g., 1-2 days). Inembodiments, the location of the vaults may be within a distance thatallows segments of key pairs to be retrieved within a redemption waitingperiod (e.g., 3 days). A complete key set (e.g., stored private keysparts 1-3) may be stored in each vault general location (e.g., LocationA, Location B, Location C).

In FIG. 31A, three segments have been used, but other numbers ofsegments can also be used consistent with embodiments of the presentinventions. FIG. 31B illustrates that any number of vault generallocations (e.g., A-N) may be used, which may entail N number of completekey sets. In embodiments, the keys may be broken into any number of keysegments, 1-N. In embodiments, in order to reassemble one complete key,all N segments may have to be reassembled together.

In embodiments, there may be two sets of segmented keys, as illustratedin FIG. 31C, which may be located in two general locations (e.g., A andB). In embodiments, the keys may be parsed into two segments (e.g., 80-1and 80-2), as illustrated in FIG. 31C.

In embodiments, duplicate sets may not be embodied in same form as theoriginal set and/or other duplicate sets. For example, two sets may bestored on paper, and a third set is stored on papyrus. In embodiments,at least one set of segmented keys can be stored on paper, while atleast one set is stored on one or more disks, memory sticks, memorycards, tapes, hard drives, or other computer readable media. Inembodiments, the same number of segments can be used for each set. Inembodiments, a different number of segments can be used for at least twoof the sets (e.g., 3 segments for 1 set, and 4 segments for 1 set). Inembodiments, different types of coding and/or encryption can be used forat least two sets. FIG. 31D illustrates three sets of key copies, wherethe third copy 80 stored in vault 70-C may not be divided into segments.Such a key copy may be encrypted like any of the other key segments.

A cold storage back-up may be provided by a one-way electronic datarecordation system. The system can function as a write-only ledger. Upondeposit of digital assets into cold storage, the corresponding privatekeys may be transmitted to the recordation system, which will store arecord of the transaction. When digital assets are removed from awallet, a record of the removal and/or wallet destruction can be sent tothe system. In the event that wallet keys must be retrieved, therecordation system can be accessed to determine the wallet keys.Accessing the recordation system to retrieve keys can be designed to bea difficult operation, only to be performed in the event of an emergencyneed to recover wallet keys.

Key Storage Service

Digital asset storage services and/or digital asset protection may beprovided in accordance with the present invention. Digital asset storagemay use any of the secure storage systems and methods described herein.In embodiments, a digital asset storage service may be provided to otherentities (e.g., a trust, authorized participants in the trust,retailers, banks, or other digital asset users), to provide securestorage of digital assets. Such a storage service may use any of thesecurity measures described herein. In embodiments, a digital assetstorage service may comprise, form a part of, and/or be associated witha digital asset insurance system, as described herein.

Digital asset protection can be digital asset insurance and/or digitalasset warranties. Digital asset insurance may be insured key storage,which may entail secure storage of one or more keys, such as privatekeys, where the secure storage service may guarantee the return of thestored private key and will pay out some amount if the key cannot bereturned. In embodiments, a digital asset warranty can be a warrantyagainst key loss, which may be a warranty against key loss by a digitalasset storage service.

A digital asset storage service and/or a digital asset protection systemmay be associated with and/or accessed through one or more digitalwallets. In embodiments, digital asset protection and/or storageservices may only be available when using a particular digital assetwallet and/or when employing particular storage mechanisms orprocedures. In embodiments, a digital wallet may provide an option torequest and/or accept protection and/or an option to request and/oraccept storage of one or more keys associated with the wallet. Inembodiments, a wallet may prompt and/or require a user to store theprivate key of the wallet, e.g., using the secure digital asset storageservice.

FIG. 36A illustrates an exemplary system for providing secure digitalasset storage and/or protection. A storage computer system 3320 maystore in computer-readable media or otherwise be connected to one ormore databases containing data 3335 relating to one or more digitalasset or key storage policies. In embodiments, data 3335 can alsoinclude information relating to a stored or insured digital wallet, suchas public keys, public addresses, and/or key storage information, whichmay comprise identification codes or other indicators of where keys orkey segments are stored. The storage computer system 3320 may store keydata 3325 in internal or external computer-readable memory comprisingone or more databases. Key data 3325 can include public key data,information identifying a key owner or wallet owner, information (e.g.,an identifying code) identifying or correlating a wallet's keys or keysegments, and/or information identifying location and/or retrievalinformation for stored keys or key segments, to name a few.

The exemplary system illustrated in FIG. 36A can include a plurality ofsecure storage locations, such as vaults 3305-1, 3305-2, and 3305-3.Private keys or key segments 3310-1, 3310-2, and 3310-3 may be stored ineach vault in accordance with the secure storage systems and methodsdiscussed herein, such as cold storage vaulting in different locations.Vaults may be connected to a network 15 at times and disconnected atother times. The network 15 may be any data network or a plurality ofconnected networks, internal, such as an intranet, or external, such asthe Internet. A plurality of keys corresponding to a multi-key walletmay be stored in separate vaults. In embodiments, one or more keys maybe divided into segments, which can be stored in separate vaults. Keysmay be divided whether from single private key wallets or multi-keywallets.

One or more users 3315 may be, e.g., customers and/or claimants of adigital asset storage and/or protection system. Users 3315 may obtainkey storage for one or more digital wallets containing digital assets inone or more denominations. Users 3315 may access or otherwiseparticipate in a digital asset storage and/or protection system usingone or more user device. In embodiments, the same digital wallet may beaccessed from a plurality of user devices using the same keycombinations (e.g., private and public keys).

FIG. 36B shows another exemplary embodiment of a system for providingsecure digital asset storage and/or protection. A plurality of vaults3305-1 to 3305-N may be employed to store keys or key segments insegregated locations. In embodiments, vaults may be secure locations,such as safety deposit boxes, bank vaults, rooms with controlled access,to name a few. Vaults may be physical and/or electronic repositories forkeys or key segments. In addition, each vault may have one or morebackups 3355 (e.g., Q number of backups for vault 3305-1, R number ofbackups for vault 3305-2, and S number of backups for vault 3305-N).Vault backups may be other vaults or other secure storage facilities,units, or devices. Vault backups may utilize the same or different typesof storage from each other and/or from the primary vault. For example, aprimary vault may include printed paper copies of keys or key segmentsstored in a bank lockbox, while a backup may comprise an offlineencrypted hard drive storing data corresponding to keys or key segments.Vault backups 3355 can be any of physical storage of printed ortranscribed keys or key segments, remote cloud storage, hard drive,disk, CD, DVD, memory card, flash drive, tape drive, and/or tapelibrary, to name a few.

Storage of Keys by a Digital Asset Storage Service

As discussed herein, a digital asset storage service may be provided tousers of a digital asset network to provide secure storage of digitalassets. In embodiments, the secure storage service may be used inconjunction with a digital asset protection plan, such as an insuranceor warranty plan, although the storage service may also be used withoutinsurance or warranties. FIGS. 37A-37B describe exemplary processes forstoring private keys, which may be used solely as a key storage serviceor in conjunction with protection plans, such as insurance or warrantyplans.

In embodiments, a user of a digital asset network may provide one ormore keys or key segments to the key storage service for storage. Keysor key segments may be provided to the storage service via email orother electronic data transfer, any of which may be secure or otherwiseencrypted. A user may use software to generate a wallet with one or moreprivate keys and/or to divide the keys into segments. The software mayinclude the ability to transmit, e.g., via a secure connection, the keysor key segments to the secure storage company. In embodiments, keys maybe delivered to a key storage company in person, via mail, or via fax.Such keys may be stored in accordance with the secure and cold storagevault security mechanisms discussed herein, which may include dividingthe keys into segments if not already divided.

Keys may also be generated at the secure storage company, e.g., at thesecure storage site. Accordingly, a user may log into a website orotherwise connect to a portal for accessing wallet generation software.Such software may be running on one or more processors located at thesecure storage company. The user may use the wallet generation softwareto create a wallet with one or more private keys. The user may also usesuch software to split one or more keys into key segments. Each key orkey segment may then be printed, transcribed, or otherwise prepared forstorage. In embodiments, the software may be programmed to transmit eachkey or key segment to a different printer, printing device, orelectronic storage device, any of which may be located in differentrooms, on different premises, in different geographies, and/or inseparate vaults, to name a few. Thus, the key storage service may thenstore each key or key segment in separate locations, in accordance withthe secure storage mechanisms discussed herein, such as the cold storagevault systems. Accordingly, the key storage company may never haveaccess to an assembled key or to the required plurality of keys to amulti-key wallet.

Upon a user's request for retrieval of a stored key or keys, the securekey storage company may send to the user originals or copies, physicallyor electronically, of the keys or key segments. In embodiments, the keystorage company may never reassemble keys or access a digital walletitself. The secure key storage company may charge fees at setup and/orat retrieval, as well as recurring storage fees.

FIG. 37A describes an exemplary embodiment of a process for secure keystorage and arranging for insurance or warranties against lost privatekeys, which process may be performed using a digital asset storagesystem, as discussed herein. The digital asset storage system maycomprise and/or form a part of a digital asset protection system. FIG.37A refers to the storage of private keys, but the process may apply tothe storage of both private and public keys.

FIG. 37A is a flow chart of an exemplary process for securely storingprivate key information, which may be performed by a secure digitalasset storage system. In step S3422, a request to store a private keymay be received at the secure digital asset storage system. Inembodiments, such a request may comprise a request for insured privatekey storage. Such a request may originate from one or more othercomputers or electronic devices, such as a mobile phone, digital assettransaction kiosk, and/or personal computer, to name a few.

In step S3424, a user may provide identification information, which maybe received at the storage system Identification information maycomprise any of a name, contact information (e.g., address, telephonenumber, e-mail address, to name a few), government ID information (e.g.,an image of a driver's license, a driver's license ID number, a passportnumber, to name a few), biometric information (e.g., a voice sample,current photograph, eye scan, fingerprint, to name a few), username,password, and/or one or more security questions, to name a few. Theidentification information may be provided by and/or correspond to therequestor of private key storage and/or the private key owner. Inembodiments, the digital asset insurance system may receive and/or storea user's identification information.

In step S3426, the storage system may obtain a private key to be stored.The storage system may receive the key or fetch it, e.g., from a userelectronic device, such as a mobile phone. In embodiments, the storagesystem may also obtain a public key to be stored.

In step S3428, the storage system may cipher the private key, asdescribed herein. In embodiments, the private key may not be cipheredbefore dividing it into segments. In other embodiments, the private keymay be encrypted.

In step S3430, the digital asset storage system may divide the cipheredprivate key into any number of segments. In the case of a multi-keywallet, the keys may not be divided into segments. However, keys to amulti-key wallet may be encrypted and/or ciphered.

In step S3432, the storage system may encrypt each private key segment.In embodiments, encryption and/or ciphering may occur only before oronly after dividing a key into segments. In embodiments, the keysegments may not be encrypted after the segments are created. The keysegments may be ciphered or not processed further.

In step S3434, the storage system may transfer each encrypted privatekey segment to a different electronic vault for storage. In embodiments,the vaults may not be electronic, and the key segments may be printed orotherwise transcribed on a physical substrate and stored in the vaults.Any number of vaults may be used (e.g., one vault for each key segment,multiple vaults for redundant copies of each key segment, one or morevaults with two or more key segments stored together, to name a few). Acode, such as a bar code or QR code, may be provided along with the keysegments (e.g., printed with a physically transcribed copy of a keysegment electronically saved with an electronic key segment, or appendedto an electronic key segment, to name a few). The code may identify thekey segments (e.g., which key segments are part of the same key) and/orthe order of the key segments.

In step S3436, the storage system may store, in one or more databases,key storage plan information (e.g., a subscription for key storagecosting $1.99/month), user identification information, private keysegment vault location information, and decryption and decipheringinstructions. The databases may be computer-readable databases orphysical (e.g., paper) databases that may be scanned and then read byone or more computers. In embodiments, the stored information may besent to a user and/or an storage system administrative coordinator,which may be a computer that can handle retrieval of stored keys.

In step S3438, the digital asset storage system may send confirmation ofprivate key storage (e.g., over a data transfer network) to the user(e.g., requestor of private key storage or other person associated withthe received identification information) and/or a third party.Confirmation of storage may be recorded by the storage system and/oranother entity associated with the storage system.

FIG. 37B illustrates that physical back-ups of the secured private keymay be employed by a secure digital asset storage system. In step S3442,a request to store a private key may be received at the storage system.

In step S3444, the storage system may receive user or digital walletowner account identification information.

In step S3446, the storage system may obtain (e.g., receive or fetch) aprivate key.

In step S3448, the storage system may cipher the private key. Inembodiments, no ciphering may occur before dividing the key intosegments.

In step S3450, the storage system may divide the private key (orciphered private key) into segments.

In step S3452, the storage system may cipher each private key segment.

In step S3454, the storage system may print each ciphered private keysegment. One or more copies of the key segments may be printed and/orotherwise transcribed onto any substrate and/or multiple substrates(e.g., paper, plastic, metal, to name a few). A code, such as a QR codeor bar code, may be used to identify corresponding key segments and/orthe order of the key segments. Such a code may be printed or otherwiseprovided with the key segments.

In step S3456, the digital asset storage system may store each cipheredprivate key segment, as discussed herein. The key segments may be storedin electronic vaults (e.g., hard drives, tape drives, solid statememory, to name a few). Separate vaults may be used for each keysegment, although multiple key segments corresponding to multipledifferent private keys may be stored in the same vault.

In step S3458, the storage system may store each printed key segment ina physical vault, which may be separate vaults for each key segment.

In step S3460, the storage system may store, in one or more databases,key storage plan information, user identification information, privatekey segment vault location information, deciphering instructions, anddecryption instructions, where applicable.

In step S3462, the storage system may send confirmation of private keystorage to the user.

Recovering Stored Keys from a Digital Asset Key Storage Service

A user of a secure storage service or system may request access to astored key, which may be a means of recovering a lost key.

FIG. 38A is a flow chart describing an exemplary process for recoveringa key, which may be performed by one or more computers. In embodiments,the process may entail recovering (e.g., retrieving from storage) aplurality of keys or key segments.

In step S3502, a user may submit a claim for a lost private key, whichmay be received by a computer system of a secure storage service storinga copy of the user's private key. A claim may be a request for retrievalof one or more stored keys.

In step S3504, the storage system, using the computer system, maycorrelate the received claim to one or more locations where private keysegments are stored. For example, the computer system may access adatabase of policy information to determine where (e.g., in whichvaults) a claimants keys or key segments are stored.

In step S3506, a message, which may constitute instructions, may betransmitted to one or more storage facilities to retrieve the privatekey segments. A computer system may automatically generate such amessage based upon the information pertaining to stored keys or keysegments. Such a key retrieval message can include a security code orother authorization to access a secure storage location. In embodiments,the computer system may employ security measures, such as a secure codeor digital signature, to provide verification and/or authentication of aretrieval message.

In step S3508, the private key segments may be verified. Keys or keysegments may be retrieved from their respective storage locations.Quality control measures may verify that the correct key segments wereretrieved and/or that the keys or key segments are readable, e.g., by aspecially programmed scanning device, such as a QR scanner.

In step S3510, the private key segments may be transmitted to a deviceand/or account corresponding to the user. One or more securetransmissions may be used. Two-factor authentication may be required ofthe recipient before a transmission is sent and/or opened by therecipient. In embodiments, the system may decrypt, reassemble, and/ordecipher private keys and/or key segments before returning the keysand/or key segments to a user. In embodiments, a user may be providedwith the option of having the system perform the decrypting,reassembling, and/or deciphering steps. In embodiments, software may beprovided to a user to enable such steps to be performed by a user orunder a user's control. In embodiments, the computer system may neverdecrypt keys or key segments that were encrypted by a user. Accordingly,in step S3510, the user may be provided with key segments and/orreassembled keys, which may be in various states of security (e.g.,ciphered, segmented, and/or encrypted).

In step S3512, the system may receive confirmation that the userreceived the private keys or key segments. A user device mayautomatically generate and/or transmit a confirmation upon receipt ofthe keys or key segments, upon reassembling thereof, upon opening acorresponding digital asset wallet, or upon instruction for a user, toname a few. Such confirmation may provide an indication that the securestorage service and/or protection service met its obligation, e.g., tothe customer.

FIG. 38B illustrates another exemplary process for recovering a key.Such process may be performed by one or more computers. The process maybe considered the same as the process of FIG. 38A, except with theaddition of a user authentication step S3524.

Thus, In step S3522, a user may submit a claim for a lost private key,which may be received by a secure storage service storing a copy of theuser's private key.

In step S3524, the secure storage system may authenticate the identityof the claimant. Authentication may involve any of receipt of any of auser's identification information, such as name, username, password,biometric information, or the like. In embodiments, three forms ofidentification information may be required. In embodiments, a claimantmay receive a phone call, which may be auto-generated and auto-executedby the system, which may provide the claimant with a code to input at auser device. In embodiments, the user may be required to repeat aphrase, which may be a unique phrase. Voice analysis and/or recognitiontechniques may be employed. The user may be required to submit a currentpicture or video. The system may compare the received identificationinformation to a database of authorized user identification informationin order to authenticate the identity of the claimant.

In step S3526, the system may correlate the received claim to one ormore locations where private key segments may be stored.

In step S3528, a message, which may constitute instructions, may betransmitted to one or more storage facilities to retrieve the privatekey segments.

In step S3530, the private key segments may be verified.

In step S3532, the private key segments may be transmitted to a deviceand/or account corresponding to the user. In embodiments, decryption,reassembly, and or deciphering of private keys and/or key segments mayoccur before or after returning the keys and/or key segments to a userand may be performed by the system or by a user, who may use softwareprovided by the system.

In step S3534, the system may receive confirmation that the userreceived the private key segments.

Another exemplary process for recovering a key is provided in FIG. 38C.Such process may be performed by one or more computers. The process maybe considered the same as the process of FIG. 38B, except with theaddition of steps to check the account balance of the account and adetermination step of whether to proceed with the key retrieval.

Thus, In step S3542, a user may submit a claim for a lost private key,which may be received by a secure storage service storing a copy of theuser's private key.

In step S3544, the secure storage system may authenticate the identityof the claimant, in manners described for step S3524 of FIG. 38B.

In step S3546, the system may check the account balance of the account.

In step S3548, the system may determine whether to proceed with therequested key retrieval. In embodiments, retrieval may be halted if anaccount balance is above a threshold or below a threshold.

In step S3550, the system may correlate the received claim to one ormore locations where private key segments may be stored.

In step S3552, a message, which may constitute instructions, may betransmitted to one or more storage facilities to retrieve the privatekey segments.

In step S3554, the private key segments may be verified.

In step S3556, the private key segments may be transmitted to a deviceand/or account corresponding to the user of the account. In embodiments,decryption, reassembly, and or deciphering of private keys and/or keysegments may occur before or after returning the keys and/or keysegments to a user and may be performed by the system or by a user, whomay use software provided by the system.

In step S3558, the system may receive confirmation that the userreceived the private key segments.

In exemplary embodiments, a user of a secure storage service or systemmay be required to provide proof of control of an account before a lostkey for that account may be recovered and provided to the user.Exemplary systems and methods for implementing such proof of control aredescribed in further detail below.

Increasing the Total Supply of Digital Asset Tokens

FIGS. 39A-39B illustrates a process for increasing a total supply ofdigital asset tokens in accordance with exemplary embodiments of thepresent invention. The process of FIGS. 39A through 39B may begin at astep S3902. At step S3902, a first designated key pair (e.g. on-linekeyset 1 1362) may be provided. In embodiments, the first designated keypair may include, at least, a first designated public key and acorresponding first designated private key. The first designated publickey, in embodiments, may be used to provide a first designated publicaddress, which may be associated with an underlying digital asset. Theunderlying digital asset (e.g. Neo, ether, to name a few) may bemaintained on a distributed public transaction ledger maintained in theform of a blockchain. In embodiments, a first computer system may storethe first designated private key, similarly to on-line keyset 1 1362.The first computer system may have access to, or be connected with, thedistributed public transaction ledger through a network, such as theinternet (e.g. network 15). In embodiments, the first designated privatekey may be mathematically related to the first designated public key. Inembodiments, the first designated public address is the first designatedpublic key. In embodiments, the first designated public address isderived from the first designated public key.

In embodiments, the first designated key pair may include a plurality ofkey pairs (e.g. on-line keyset N 1362N). For example, the firstdesignated key pair may further include a first additional designatedpublic key and a corresponding first additional designated private key.In embodiments, each key pair of the aforementioned plurality of keypairs of the first designated key pair may each correspond to adesignated public address. For example, a first key pair of theplurality of key pairs may correspond to a first designated publicaddress associated with the underlying digital asset. A second key pairof the plurality of key pairs may correspond to a second designatedpublic address associated with the underlying digital asset. Inembodiments, each key pair of the aforementioned plurality of key pairsmay correspond to the same designated public address. For example, thefirst and second key pairs mentioned in the examples above may beassociated with the same designated public address.

In embodiments, the first designated public address may be derived byusing and/or applying a cryptographic hash function of the firstdesignated public key. In embodiments, the first designated publicaddress is a result of the cryptographic hash function, or, inembodiments, at least a part of the result of the cryptographic hashfunction. A cryptographic hash function may be a hash function that is amathematical algorithm which maps data of arbitrary size to a bit stringof a fixed size (e.g. a hash). In embodiments, the cryptographic hashfunction may be designed to be a one-way function (e.g. a function thatis infeasible to invert). The cryptographic hash function, may includeone or more of the following prosperities: (1) deterministic such thatthe same message produces results in the same hash; (2) high speed, suchthat the hash value for a message is computed in a manner that does notslow the process down; (3) infeasible to generate a message from thehash, such that generating a message from the hash value would requireattempting all possibilities (e.g. a brute force approach); and (4)unique, such that messages to not have the same hash value and/or smallchanges to a message alter the hash value such that the values do notcorrelate, to name a few.

The process of FIGS. 39A through 39B may continue at a step S3904. Atstep S3904, a second designated key pair (e.g. off-line keyset 1 1803)is provided. The second designated key pair, similar to the firstdesignated key pair, may include a second designated public key and acorresponding second designated private key. The second designatedpublic key may be mathematically related to the corresponding seconddesignated private key. In embodiments, the second designated key pairmay correspond to the same public address as the first designated keypair (e.g. the first designated public address associated with theunderlying asset). In embodiments, the second designated key pair maycorrespond to a different public address than the first designated keypair. For example, the first designated key pair may correspond to thefirst designated public address and the second designated key pair maycorrespond to a second designated public address. In embodiments, wherethe second designated key pair corresponds to a second designated publicaddress, the second designated public address may be the seconddesignated public key.

In embodiments, the second designated key pair may be stored on a secondcomputer system. The second computer system may be physically and/oroperationally separated from the first computer system. Additionally,the second computer system may be physically and/or operationallyseparated (e.g. not connected to) from the distributed publictransaction ledger and/or the internet (e.g. network 15). Thisseparation, as described above in connection with FIG. 18A, may be forsecurity purposes, adding an additional layer of security by ensuringthat unwanted access is not granted via network 15.

In embodiments, the second computer system may be a hardware storagemodule. The hardware storage module may be located in a vault (e.g.Vault 70-A1) Location A, Location B, Location C . . . Location Ndescribed above in connection with FIGS. 31A-31D. Additionally, a moredetailed description of storage, and particularly cold storage, islocated above under the “Cold Storage” heading.

In embodiments, the hardware storage module, may include one or moretypes of storage mediums such as any volatile or non-volatile memory, orany removable or non-removable memory implemented in any suitable mannerto store the second designated key pair. For example, the seconddesignated key pair may be stored using computer-readable instructions,data structures, and/or program systems. Various types of storage/memorymay include, but are not limited to, hard drives, solid state drives,flash memory, permanent memory (e.g., ROM), electronically erasableprogrammable read-only memory (“EEPROM”), CD-ROM, digital versatile disk(“DVD”) or other optical storage medium, magnetic cassettes, magnetictape, magnetic disk storage or other magnetic storage devices, RAIDstorage systems, or any other storage type, or any combination thereof,to name a few.

In embodiments, the second designated key pair may include a pluralityof key pairs (e.g. off-line keyset N 1803N). For example, the seconddesignated key pair may further include a first additional designatedpublic key and a corresponding first additional designated private key.In embodiments, each key pair of the aforementioned plurality of keypairs of the second designated key pair may each correspond to adesignated public address. For example, a first key pair of theplurality of key pairs may correspond to a first designated publicaddress associated with the underlying digital asset. A second key pairof the plurality of key pairs may correspond to a second designatedpublic address associated with the underlying digital asset. Inembodiments, each key pair of the aforementioned plurality of key pairsmay correspond to the same designated public address. For example, thefirst and second key pairs mentioned in the examples above may beassociated with the same designated public address.

In embodiments, the second designated public address may be derived byusing and/or applying a cryptographic hash function of the seconddesignated public key. In embodiments, the second designated publicaddress is a result of the cryptographic hash function, or, inembodiments, at least a part of the result of the cryptographic hashfunction. The cryptographic hash function applied may be similar and/orthe same cryptographic hash function applied to the first designated keypair. In embodiments, the cryptographic hash function applied to thesecond designated key pair may be different than the cryptographic hashfunction applied to the first key pair. A different cryptographic hashfunction may be used, in embodiments, as an additional security measure.

In embodiments, the process of FIG. 39A may continue with step S3906where first smart contract instructions (e.g. PROXY ContractInstructions 1310A-1) associated with a first smart contract (e.g. PROXYSmart Contract 1310) are provided. The first smart contract may have acorresponding first contract address (e.g. Contract Address 1 of ProxySmart Contract 1310) associated with the blockchain of the underlyingdigital asset. In embodiments, the first smart contract instructions maybe saved as part of the blockchain of the underlying digital assetand/or include one or more of the following instructions: (1) firstdelegation instructions and/or (2) first authorization instructions, toname a few. The first delegation instructions may delegate one or morefirst functions associated with the digital asset token to one or moredelegated contract addresses associated with the blockchain of theunderlying digital asset. The one or more delegated contract addresses,in embodiments, may be different than the first contract address. Forexample the one or more delegated contract addresses may include asecond contract address, which may be different than the first contractaddress. The first delegation instructions may similar to the delegationinstructions described above in connection with PROXY DelegationInstructions Module 1829.

The first authorization instructions, in embodiments, may be associatedwith the second designated key pair. In embodiments, first authorizationinstructions may be similar to the authorization instructions describedabove in connection with PROXY Authorization Instructions Module 1831.

In embodiments, the first smart contract may be PROXY smart contract1310 described above in connection with FIGS. 18A and 18B, thedescription of which applying herein.

The process or FIG. 39A may continue with step S3908 where second smartcontract instructions (e.g. PRINT LIMITER Contract Instructions 1360A-1)associated with a second smart contract (e.g. PRINT LIMITER SmartContract 1360) is provided. The second smart contract may be associatedwith a second contract address (e.g. Contract Address 3 described abovein connection with the PRINT LIMITER Smart Contract 1360) associatedwith the blockchain of the underlying digital asset. The second smartcontract instructions may be saved as part of the blockchain for theunderlying digital asset and/or include one or more of the followinginstructions: (1) print limiter token creation instructions, (2) secondauthorization instructions, and/or (3) third authorization instructions,to name a few.

The print limiter token creation instructions, in embodiments, mayindicate one or more conditions under which digital asset tokens of theunderlying digital asset are created. In embodiments, the print limitertoken creation instructions may be similar to the PRINT LIMITER tokencreation instructions described above in connection with the PRINTLIMITER Token Creation Instructions Module 1833.

The second authorization instructions, in embodiments, may includeinstructions to create tokens of the digital asset token. Inembodiments, the first designated key pair is designated to authorizethe second authorization instructions. In embodiments, the seconddesignated key pair is designated to authorize the second authorizationinstructions. The second authorization instructions, in embodiments, mayinclude instructions limiting the creation of digital asset tokens. Thelimitation placed on token creation may prevent the creation of tokensabove a first threshold. For example, the second authorizationinstructions may limit the creation of tokens to 100,000 tokens. Inembodiments, the first threshold may be relative to a first period oftime. For example, the second authorization instructions may limit thecreation of tokens to 500,000 tokens per day. In embodiments, the secondauthorization instructions may be similar to the first authorizationinstructions described above in connection with PRINT LIMITER FirstAuthorization Instructions Module 1839.

The third authorization instructions, in embodiments, may also includeinstructions with respect to token creation. In embodiments, the thirdauthorization instructions may designate a first designated custodianaddress (e.g. a custodian address associated with CUSTODIAN 2 SmartContract 1350) with respect to token creation of the digital assettoken. In embodiments, the third authorization instructions may besimilar to the second authorization instructions described above inconnection with PRINT LIMITER Second Authorization Instructions Module1841.

In embodiments, the second smart contract instructions may also includetoken balance modification instructions (e.g. instructions of the TokenBalance Modification Instructions Module 1847). The token balancemodification instructions may be related to modifying the total balanceof tokens of the digital asset token assigned to a third delegatedcontract address. In embodiments, the third delegated contract addressmay be of the one or more delegated contracted addresses. Inembodiments, the token balance modification instructions may be similarto the optional token balance modification instructions described abovein connection with Token Balance Modification Instructions Module 1847.

In embodiments, the second smart contract may further include additionalauthorization instructions. The additional authorization instructionsmay be similar to the optional PRINT LIMITER THIRD Authorizationinstructions described above in connection with PRINT LIMITER Thirdauthorization Instructions Module 1835.

In embodiments, the second smart contract may be PRINT LIMITER SmartContract 1360 described above in connection with FIGS. 18A and 18C, thedescription of which applying herein.

In embodiments, the process of FIG. 39A may continue with step S3910where third smart contract instructions (e.g. CUSTODIAN 2 ContractInstructions 1350A-1) associated with a first designated custodiancontract (e.g. CUSTODIAN 2 Smart Contract 1350). In embodiments, thefirst designated custodian contract is associated with a third contractaddress (e.g. Contract Address 6 of CUSTODIAN 2 Smart Contract 1350)associated with the blockchain of the underlying digital asset. Inembodiments, the third contract address is the first designated contractaddress designated by the third authorization instructions of the secondsmart contract. In embodiments, the third smart contract instructionsare saved as part of the blockchain of the underlying digital assetand/or include one or more of the following instructions: (1) fourthauthorization instructions (e.g. authorization instructions described inconnection with CUSTODIAN 2 First Authorization Instructions Module1849), and/or (2) sixth authorization instructions (e.g. authorizationinstructions described in connection with CUSTODIAN 2 SecondAuthorization Instructions Module 1851), to name a few.

The fourth authorization instructions, in embodiments, may authorize theissuance of instructions to the second smart contract. The issuedinstructions that are authorized by the fourth authorizationinstructions may regard token creation. In embodiments, the fourthauthorization instructions designate the second designated key pair toauthorize the fourth authorization instructions. In embodiments, thefourth authorization instructions designate the first key pair toauthorize the fourth authorization instructions. In embodiments, thefourth authorization instructions include instructions to permit thecreation of digital asset tokens above a first threshold defined by thesecond authorization instructions. In embodiments, the fourthauthorization instructions may be similar to the authorizationinstructions described in connection with CUSTODIAN 2 FirstAuthorization Instructions Module 1849.

The sixth authorization instructions, in embodiments, may designate aseventh contract address as one of the one or more delegated contractaddresses. In embodiments, the seventh contract address is not thesecond contract address. In embodiments, the second designated key pairis designated to authorize the sixth authorization instructions. Inembodiments, the first designated key pair is designated to authorizethe sixth authorization instructions. In embodiments, the sixthauthorization instructions may be similar to the authorizationinstructions described in connection with CUSTODIAN 2 SecondAuthorization Instructions Module 1851.

In embodiments, the third smart contract may be CUSTODIAN 2 SmartContract 1350 described above in connection with FIGS. 18A and 18D, thedescription of which applying herein.

In embodiments, the process of FIG. 39A may continue with step S3912where fourth smart contract instructions (e.g. IMPL Smart ContractInstructions 1320A-1) associated with a fourth smart contract (e.g. IMPLSmart Contract 1320). In embodiments, the fourth smart contract isassociated with a fourth contract address (e.g. Contract Address 2 ofIMPL Smart Contract 1320), to name a few. The fourth contract address,in embodiments, may be one of the one or more delegated contractaddress. Additionally, the fourth contract address, in embodiments, maybe different from one or more of: the first contract address, the secondcontract address, and/or the third contract address. The fourth smartcontract instructions may be saved as part of the blockchain and/orinclude one or more of the following instructions: (1) token creationinstructions (e.g. instructions of IMPL Token Creation InstructionsModule 1865), (2) second delegation instructions (e.g. instructions ofIMPL Delegation Instructions Module 1837), (3) token transferinstructions (e.g. instructions of IMPL Token Transfer InstructionsModule 1861), and/or (4) token destruction instructions.

The token creation instructions may, in embodiments, be instructions tocreate tokens of the digital asset tokens. In embodiments, the tokencreation instructions may create tokens in accordance with theconditions set forth by the print limiter token creation instructions ofthe second smart contract. The token creation instructions may besimilar to instructions described in connection with the IMPL TokenCreation Instructions Module 1865.

The second delegation instructions, in embodiments, may delegate datastorage operations to at least a fifth contract address. In embodiments,the fifth contract address may be associated with Contract Address 4 ofSTORE Smart Contract 1330. For example, the second delegationinstructions may cause STORE Smart Contract 1330 to execute storageinstructions of Storage Instructions Module 1853. The second delegationinstructions may be similar to instructions described in connection withIMPL Delegation Instructions Module 1861.

In embodiments, the token transfer instructions may be related totransferring issued tokens of the digital asset token. The transfer oftokens may be from a first designated contract address to a seconddesignated contract address. For example, issued tokens may betransferred from a contract address associated with a digital assettoken issuer system to a user public address associated with a userattempting to purchase tokens of the underlying digital asset. The tokentransfer instructions may be similar to instructions described inconnection with IMPL Token Transfer Instructions Module 1859.

In embodiments, the token destruction instructions may be related todestroying and/or burning one or more issued tokens of the digital assettoken. For example, if a user is attempting to exchange a token for, asan example, fiat, the token being exchanged may be burned once the tokenis exchanged for fiat.

In embodiments, the fourth smart contract may be IMPL Smart Contract1320 described above in connection with FIGS. 18A and 18F, thedescription of which applying herein.

In embodiments, the process of FIG. 39A may continue with the process ofFIG. 39B. The process of FIG. 39B may continue with step S3914 wherefifth smart contract instructions (e.g. STORE Contract Instructions1330A-1) associated with a fifth smart contract (e.g. STORE SmartContract 1330) are provided. The fifth contract address, in embodiments,may be one of one or more designated store contract addresses. Inembodiments, the fifth smart contract instructions may be saved as partof the blockchain of the underlying digital asset and/or include one ormore of the following instructions: (1) data storage instructions (e.g.instructions of Storage Instructions Module 1853) and/or (2) fifthauthorization instructions (e.g. instructions of STORE AuthorizationInstructions Module 1855), to name a few.

The data storage instructions, in embodiments, may include instructionsto store transaction data related to the digital asset token.Transaction data, in embodiments, may include transaction informationfor one or more of the issued tokens of the digital asset token. Thetransaction information, may include at least one of: (1) respectivepublic address information associated with the blockchain of theunderlying digital asset, and/or (2) corresponding respective tokenbalance information which may be associated with the aforementionedrespective public address information. In embodiments, the transactiondata may include transaction information for all of the issued tokens ofthe digital asset token. In embodiments, the data storage instructionsmay be similar to instructions described in connection with StorageInstructions Module 1853.

The fifth authorization instructions may include authorizationinstructions to modify the transaction data in response to a request. Inembodiments, the request may be received from the fourth contractaddress. The fifth authorization instructions may be similar toinstructions described above in connection with STORE AuthorizationInstructions 1855.

In embodiments, the fifth smart contract may be STORE Smart Contract1330 described above in connection with FIGS. 18A and 18E, thedescription of which applying herein.

In embodiments, the process of FIG. 39B may continue with step S3916where the total supply of digital asset tokens may be increased by adigital asset token issuer system. In embodiments, the total supply ofdigital asset tokens may be increased from a first amount to a secondamount. A more detailed description of the process of step S3916 islocated in the flow charts of FIGS. 39C-39E.

Referring to FIG. 39C, the process of increasing the total supply ofdigital asset tokens may begin with step S3920 where a first transactionrequest may be generated. The first transaction request may include afirst message that may include a first request to increase the totalsupply of digital asset tokens to the second amount of digital assettokens. In embodiments, the first transaction request may be sent from acontract address associated with the digital asset token issuer systemto the fourth contract address. In embodiments, the first transactionrequest may be digitally signed by the first designated private key. Inembodiments, the first transaction request may be signed by the seconddesignated private key. In embodiments, the first transaction requestmay include first transaction fee information for minors associated withthe plurality of geographically distributed computer systems in thepeer-to-peer network. The first transaction fee information may be apredetermined amount of currency which may be related to the cost ofprocessing the first transaction request.

In embodiments, the first request may be to decrease the total supply ofdigital asset tokens to a third amount. This example may follow the sameprocess described in connection with FIGS. 39C-39E, with the thirdamount of digital asset tokens being less than the first amount ofdigital asset tokens.

The process may continue with a step S3922. In embodiments, at stepS3922, the first transaction request may be sent by the digital assettoken issuer system, from the first designated public address to thefourth contract address. In embodiments, the first transaction requestmay be sent via the blockchain of the underlying digital asset. Inembodiments, the first transaction request may be sent via network 15.

The process may continue with step S3924 where the first transactionrequest may be sent from the fourth contract address to the secondcontract address via the blockchain for the underlying digital asset. Inembodiments, once the first transaction request is received by thesecond contract address, the second smart contract may execute the firsttransaction request. The execution of the first transaction request may,in embodiments, be to return a first unique lock identifier associatedwith the first transaction request. In embodiments, the firsttransaction request is executed via the plurality of geographicallydistributed computer systems in the peer-to-peer network with referenceto the blockchain for the underlying digital asset.

In embodiments, the process may continue with step S3926, where thedigital asset token issuer system may obtain the first unique lockidentifier. In embodiments, the first unique lock identifier may beobtained based on reference to the blockchain for the underlying digitalasset.

In embodiments, the process may continue with step S3928 where a secondtransaction request may be generated by the digital asset token issuersystem. In embodiments, the second transaction request may be generatedin response to the first unique lock identifier being obtained. Thesecond transaction request may, in embodiments, include a second messagewhich may include a second request to unlock the total supply of thedigital asset tokens. The second request may be in accordance with thefirst request. Moreover, in embodiments, the second request may includethe first unique lock identifier. In embodiments, the second transactionrequest may be digitally signed by the first designated private key. Inembodiments, the second transaction request may be digitally signed bythe second designated private key. In embodiments, the secondtransaction request may include second transaction fee information forminors associated with the plurality of geographically distributedcomputer systems in the peer-to-peer network. The second transaction feeinformation may be a predetermined amount of currency which may berelated to the cost of processing the second transaction request.

The process of FIG. 39C may continue with the process of FIG. 39D.Referring to FIG. 39D, the process may continue with step S3930 wherethe second transaction request may be sent from the first designatedpublic address to the third contract address. In embodiments, the secondtransaction request is sent by the digital asset token issuer system viathe blockchain for the underlying digital asset. In embodiments, inresponse to receiving the second transaction request, the third smartcontract may execute the second transaction request. Executing thesecond transaction request, in embodiments, may include returning afirst unique request hash associated with the second transactionrequest. In embodiments, the second transaction request is executed viathe plurality of geographically distributed computer systems in thepeer-to-peer network with reference to the blockchain associated withthe underlying digital asset.

The process may continue with step S3932 where, in embodiments, thefirst unique request hash may be obtained by the digital asset tokenissuer system. In embodiments, the first unique request hash may beobtained based on reference to the blockchain for the underlying digitalasset.

At a step S3934, in embodiments, a third transaction request may begenerated. The third transaction request may, in embodiments, begenerated to be digitally signed by at least the second designatedprivate key. In embodiments, the third transaction request may includethe first unique request hash. The third transaction request, inembodiments, may be generated in response to the digital asset tokenissuer system obtaining the first unique request hash.

In embodiments, at a step S3936, the third transaction request may betransferred to a first portable memory device. In embodiments, the thirdtransaction request may be transferred to the first portable memorydevice by an administrator (e.g. an administrator of administratorsystem 1801). In embodiments, the third transaction request may betransferred from the digital asset token issuer system to the firstportable memory device. In embodiments, the first portable memorydevice, may include one or more types of storage mediums such as anyvolatile or non-volatile memory, or any removable or non-removablememory implemented in any suitable manner to store the third transactionrequest. For example, the third transaction request may be stored usingcomputer-readable instructions, data structures, and/or program systems.Various types of storage/memory may include, but are not limited to,hard drives, solid state drives, flash memory, permanent memory (e.g.,ROM), electronically erasable programmable read-only memory (“EEPROM”),CD-ROM, digital versatile disk (“DVD”) or other optical storage medium,magnetic cassettes, magnetic tape, magnetic disk storage or othermagnetic storage devices, RAID storage systems, or any other storagetype, or any combination thereof, to name a few.

In embodiments, the process may continue with step S3938 where the thirdtransaction request may be transferred from the first portable memorydevice to the second computer system. In embodiments, the thirdtransaction request may be transferred to the second computer system byan administrator (e.g. an administrator of administrator system 1801).

In embodiments, the process of FIG. 39D may continue with FIG. 39E.Referring to FIG. 39E, at a step S3940, the second computer systemdigitally may sign the third transaction request using the seconddesignated private key. By digitally signing the third transactionrequest, the second computer system may generate a third digitallysigned transaction request.

In embodiments, once the third digitally signed transaction request isgenerated, the third digitally signed transaction request may betransferred from the second computer system to a second portable memorydevice. The second portable memory device may, in embodiments, be thefirst portable memory device (e.g. the first and second portable memorydevice are the same portable memory device). In embodiments, the secondportable memory device may be physically and operatively separate fromthe first portable memory device. In embodiments, the second portablememory device, may include one or more types of storage mediums such asany volatile or non-volatile memory, or any removable or non-removablememory implemented in any suitable manner to store the third transactionrequest. For example, the third transaction request may be stored usingcomputer-readable instructions, data structures, and/or program systems.Various types of storage/memory may include, but are not limited to,hard drives, solid state drives, flash memory, permanent memory (e.g.,ROM), electronically erasable programmable read-only memory (“EEPROM”),CD-ROM, digital versatile disk (“DVD”) or other optical storage medium,magnetic cassettes, magnetic tape, magnetic disk storage or othermagnetic storage devices, RAID storage systems, or any other storagetype, or any combination thereof, to name a few.

In embodiments, the process may continue with step S3942 where the thirddigitally signed transaction request may be sent from the portablememory device to the third contract address using the digital assettoken issuer system, via the blockchain for the underlying digitalasset. In embodiments, the portable memory device may be the secondportable memory device. To send the third digitally signed transactionrequest, in embodiments, the third digitally signed transaction requestmay be first transferred from the second portable memory device to thedigital asset token issuer system. Once transferred, in embodiments, thethird digitally signed transaction request may be sent by the digitalasset token issuer system to the third contract address.

In response to receiving the third digitally signed transaction request,in embodiments, the third smart contract may execute the third digitallysigned transaction request. In embodiments, the execution of the thirddigitally signed transaction request may result in a request to validatethe second request to unlock the total supply of digital asset tokensbased on the third digitally signed transaction request and/or the firstunique request hash. In embodiments, the execution may also result in afirst call to the second contract address. The first call may be toincrease the total supply of the digital asset tokens from the firstamount to the second amount. In embodiments, the third smart contractmay execute the third digitally signed transaction request via theplurality of geographically distributed computer systems in thepeer-to-peer network with reference to the blockchain of the underlyingdigital asset.

The first call sent by the third smart contract to the second contractaddress of the second smart contract may, in embodiments, result in thesecond contract address returning the first call to the fourth contractaddress. The fourth contract address may, in response to receiving thereturned first call, execute a second call to the fifth contractaddress. The second call, in embodiments, may be to set the total supplyof the digital asset tokens to the second amount of digital assettokens. In embodiments, the fourth smart contract may execute the secondcall via the plurality of geographically distributed computer systems inthe peer-to-peer network with reference to the blockchain of theunderlying digital asset.

The second call sent by the fourth smart contract to the fifth contractaddress of the fifth smart contract may, in embodiments, result in thefifth smart contract executing the second call to set the total supplyof the digital asset tokens to the second amount of digital assettokens. In embodiments, the fifth smart contract may execute the secondcall via the plurality of geographically distributed computer systems inthe peer-to-peer network with reference to the blockchain of theunderlying digital asset.

In embodiments, the steps of the process described in connection withFIGS. 39C-39E may be rearranged or omitted.

Referring back to FIG. 39B, the process may continue with step S3918,where the digital asset token issuer system may confirm the total supplyof digital asset tokens. The total supply, in embodiments, may beconfirmed by the digital asset token issuer system as set to the secondamount of digital asset tokens based on reference to the blockchain ofthe underlying digital asset.

In embodiments, the digital asset token issuer system may determine thatthe total supply of digital asset tokens is not the second amount ofdigital asset tokens. For example, the digital asset token issuer systemmay determine that the total supply of digital asset tokens is set to athird amount, the third amount being different than the second amount ofdigital asset tokens. In these embodiments, the digital asset tokenissuer system may generate and/or send a warning message for anadministrator (e.g. an administrator of administrator system 1801). Inembodiments, the administrator system may be the token issuer system. Inembodiments, the administrator system may not be the token issuersystem. The warning message may include a notification stating that theamount of tokens is incorrect and/or needs to be fixed. Additionally,the warning message may include a transaction ledger (e.g. NetworkDigital Asset Transaction Ledger 3228). Moreover, the warning messagemay include the third amount of digital asset tokens. Furthermore, thewarning message may include the intended amount of digital asset tokens(e.g. the second amount of digital asset tokens). In embodiments, if thedigital asset token issuer system determines the total supply of tokensis incorrect, the digital asset token issuer system may repeat one ormore of the steps of the processes described above in connection withFIGS. 39A-39E in order to set the amount of digital asset tokens fromthe third amount to the second amount.

In embodiments, the steps of the process described in connection withFIGS. 39A-39B may be rearranged or omitted.

In embodiments, a process for increasing a total supply of digital assettokens including may begin with providing a first designated key pair.The first designated key pair, In embodiments, may include a firstdesignated public key and a corresponding first designated private key.The first designated private key may also correspond to a firstdesignated public address associated with an underlying digital asset.In embodiments, the underlying digital asset is maintained on adistributed public transaction ledger maintained in the form of ablockchain by a plurality of geographically distributed computer systemsin a peer-to-peer network in the form of a blockchain network. Inembodiments, the first designated private key is stored on a firstcomputer system which is connected to the distributed public transactionledger through the Internet (e.g. network 15).

In embodiments, the process may continue with providing a seconddesignated key pair. In embodiments, the second designated key pairincludes a second designated public key and a corresponding seconddesignated private key. In embodiments, the second designated public keyalso corresponds to a second designated public address associated withthe underlying digital asset. In embodiments, the second designatedprivate key is stored on a second computer system which is physicallyseparated from the first computer system and is not operatively and/orphysically connected to the distributed public transaction ledger or theInternet.

In embodiments, the process may continue with providing first smartcontract instructions associated with a first smart contract associatedwith a digital asset token associated with a first contract addressassociated with the blockchain associated with the underlying digitalasset. In embodiments, the first smart contract instructions are savedas part of the blockchain for the underlying digital assets. Inembodiments, the first smart contract instructions include firstdelegation instructions to delegate one or more first functionsassociated with the digital asset token to one or more delegatedcontract addresses associated with the blockchain associated with theunderlying digital asset. The one or more delegated contract addresses,in embodiments, is different from the first contract address. Inembodiments, a second contract address is designated as one of the oneor more delegated contract addresses. In embodiments, the first smartcontract instructions include first authorization instructions for thesecond designated key pair.

The process may continue, in embodiments, with providing second smartcontract instructions associated with a second smart contract associatedwith the digital asset token associated with the second smart contractaddress associated with the blockchain associated with the underlyingdigital asset. In embodiments, the second smart contract instructionsare saved as part of the blockchain for the underlying digital asset. Inembodiments, the second smart contract instructions may include: (1)print limiter token creation instructions indicating conditions underwhich tokens of the digital asset token are created; (2) secondauthorization instructions to create tokens of the digital asset token,wherein the first designated key pair is designated to authorize saidsecond authorization instructions to create tokens of the digital assettoken; and (3) third authorization instructions with respect to tokencreation of the digital asset token; wherein the third authorizationinstructions designate a first designated custodian address with respectto token creation of the digital asset token, to name a few.

In embodiments, the process may continue with providing third smartcontract instructions associated with a first designated custodian smartcontract associated with the digital asset token associated with a thirdcontract address associated with the blockchain associated with theunderlying digital asset. In embodiments, the third contract address isthe first designated custodian contract address. In embodiments, thethird smart contract instructions are saved as part of the blockchainassociated with the underlying digital asset. In embodiments, the thirdsmart contract instructions include fourth authorization instructions toauthorize issuance of instructions to the second smart contractregarding token creation. In embodiments, the fourth authorizationinstructions designate the second designated key pair to authorize thefourth authorization instructions.

In embodiments, the process may continue with providing fourth smartcontract instructions associated with a fourth smart contract associatedwith the digital asset token associated with a fourth contract addressassociated with the blockchain associated with the underlying digitalasset. In embodiments, the fourth contract address is one of the one ormore delegated contract addresses and not: (i) the first contractaddress, (ii) the second contract address, and/or (iii) the thirdcontract address. In embodiments, the fourth smart contract instructionsare saved as part of the blockchain associated with the underlyingdigital assets. In embodiments, the fourth smart contract instructionsinclude: (1) token creation instructions to create tokens of the digitalasset token in accordance with conditions set forth by the print limitertoken creation instructions; and/or (2) second delegation instructionsdelegating data storage operations to at least a fifth contract address,to name a few.

In embodiments, the process may continue with providing fifth smartcontract instructions associated with a fifth smart contract associatedwith the digital asset token associated with the fifth contract addressassociated with the blockchain associated with the underlying digitalasset. In embodiments, the fifth smart contract address is one of theone or more designated store contract addresses. In embodiments, thefifth smart contract instructions are saved as part of the blockchainfor the underlying digital assets. In embodiments, the fifth smartcontract instructions include: (1) data storage instructions fortransaction data related to the digital asset token, said transactiondata includes for all issued tokens of the digital asset token: (A)respective public address information associated with the blockchainassociated with the underlying digital asset; and (B) correspondingrespective token balance information associated with said respectivepublic address information; and/or (2) fifth authorization instructionsto modify the transaction data in response to requests from the fourthcontract address;

In embodiments, the process may continue with receiving, by a digitalasset token issuer system, a request to generate and assign to the firstdesignated public address a first amount of digital asset tokens;

In embodiments, the process may continue with generating, by the digitalasset token issuer system, the first amount of digital asset tokens andassigning said first amount of digital asset tokens to the firstdesignated public address increasing the total supply of the digitalasset tokens. In embodiments, generating the first amount of digitalasset tokens and assigning said first amount of digital asset tokens tothe first designated public address may include a sub-process.

The sub-process may begin with the step of generating, by the digitalasset token issuer system, and sending, using the digital asset tokenissuer system via the blockchain network, a first transaction request:(A) to the fourth contract address; and (B) including a first messageincluding a first request to generate the first amount of digital assettokens and assign said first amount of digital asset tokens to the firstdesignated public address. In embodiments; the first transaction requestis digitally signed by the first designated private key. In embodiments,the fourth smart contract executes, via the plurality of geographicallydistributed computer systems in the peer-to-peer network with referenceto the blockchain, the first transaction request to: (i) validate thefirst request and the authority of the first designated private key tocall the second smart contract to execute the first request; and (ii)send a first call to the fourth contract address to generate and assignto the first designated public address the first amount of digital assettokens. In embodiments, the fourth smart contract executes, via theplurality of geographically distributed computer systems in thepeer-to-peer network with reference to the blockchain, the first call togenerate a first unique lock identifier, and return to the second smartcontract address, the first unique lock identifier. In embodiments, inresponse to the return of the first unique lock identifier, the secondsmart contract executes, via the plurality of geographically distributedcomputer systems in the peer-to-peer network with reference to theblockchain, a call to the fourth smart contract address to confirm thefirst call with the first lock identifier. In embodiments, in response,the fourth smart contract executes, via the plurality of geographicallydistributed computer systems in the peer-to-peer network with referenceto the blockchain, the first call to execute a second call to the fifthcontract address to obtain the total supply of digital asset tokens incirculation. In embodiments, in response, the fifth smart contractexecutes, via the plurality of geographically distributed computersystems in the peer-to-peer network with reference to the blockchain,the second call and returns, to the fourth contract address, a secondamount of digital asset tokens corresponding to the total supply ofdigital asset tokens in circulation. In embodiments, in response to thereturn of the second amount, the fourth smart contract, executes via theplurality of geographically distributed computer systems in thepeer-to-peer network with reference to the blockchain, a third callrequest to the fifth contract address to set a new total supply ofdigital asset tokens in circulation to a third amount, which is thetotal of the first amount and the second amount. In embodiments, inresponse to the third call, the fifth smart contract, executes via theplurality of geographically distributed computer systems in thepeer-to-peer network with reference to the blockchain, the third calland sets a new total supply of digital asset tokens in circulation atthe third amount. In embodiments, the fourth smart contract executes,via the plurality of geographically distributed computer systems in thepeer-to-peer network with reference to the blockchain, a fourth call tothe fifth contract address to add the first amount of digital assettokens to a respective balance associated with the first designatedpublic address. In embodiments, in response, the fifth smart contractexecutes, via the plurality of geographically distributed computersystems in the peer-to-peer network with reference to the blockchain,the fourth call to set the balance of digital asset tokens in the firstdesignated public address at a fourth amount which includes the additionof the first amount to the previous balance.

The process for increasing the total supply of digital asset tokens maycontinue with confirming, by the digital asset token issuer system, thatthe balance of digital asset tokens associated with the first designatedpublic address is set to include the first amount of digital assettokens based on reference to the blockchain.

In embodiments, the second computer system is a hardware storage module.

In embodiments, the second designated key set includes an additionaldesignated key set including an additional designated public address andan additional designated private key.

In embodiments, the second authorization instructions for the firstdesignated key set with respect to token creation of the digital assettoken include instruction limiting token creation above a firstthreshold over a first period of time.

In embodiments, the fourth authorization instructions for the seconddesignated key set to authorize the issuance of instructions to thesecond smart contract instructions with respect to token creationinclude instructions to allow for creation of digital asset tokens abovethe first threshold during the first period of time.

In embodiments, the third smart contract instructions further include:(2) sixth authorization instructions to designate a seventh contractaddress as one of the one or more delegated contract addresses. Inembodiments, the seventh contract address is not the second contractaddress. In embodiments, the second designated key set is designated toauthorize the sixth authorization instructions. In embodiments, thefourth smart contract instructions further include: (3) token transferinstructions related to transferring tokens of the digital asset tokenfrom a first designated contract address to a second designated contractaddress. In embodiments, the fourth smart contract instructions furtherinclude: (3) token destruction instructions related to destroying one ormore digital asset token. In embodiments, the fourth smart contractinstructions further include: (3) token balance modificationinstructions related to modifying a total number of tokens of thedigital asset token assigned to a third designated public address. Inembodiments, the fourth smart contract instructions further include: (3)token transfer instructions related to transferring tokens of thedigital asset token from a first designated contract address to a seconddesignated contract address; and (4) token destruction instructionsrelated to destroying one or more tokens of the digital asset token.

In embodiments, the process further includes receiving, prior togenerating the first amount of digital asset tokens, a validatingrequest. In embodiments, the process further includes determining thefirst designated key set has authority to process the request togenerate the first amount of digital tokens.

In embodiments, the first transaction request includes first transactionfee information for miners in the plurality of geographicallydistributed computer systems in the peer-to-peer network to process thefirst transaction request.

In embodiments, the fifth contract returns the balance of digital assettokens to the fourth smart contract address. In embodiments, the fifthcontract returns the balance of digital asset tokens to the second smartcontract address.

In embodiments, the process further for increasing the total supply ofdigital asset tokens continues with receiving, by the plurality ofgeographically distributed computer systems in the peer-to-peer network,from a first user device associated with the first designated publicaddress, via the underlying blockchain, a second transaction request:(A) from the first designated public address; (B) to the first contractaddress; and (C) including a second message including a second requestto transfer a fifth amount of digital assets from the first designatedpublic address to a third designated public address. In embodiments, thefirst transaction request is digitally signed by the first designatedprivate key, which is mathematically related to the first designatedpublic address. In embodiments, the first user device had access to thefirst designated private key prior to sending the second transactionrequest. In embodiments, the first smart contract executes, via theplurality of geographically distributed computer systems in thepeer-to-peer network, the second transaction request to execute, via theplurality of geographically distributed computer systems in thepeer-to-peer network, a sixth call request to the fourth contractaddress to transfer a fifth amount of digital assets from the firstdesignated public address to the third designated public address;. Inembodiments, in response to the sixth call request, the fourth smartcontract, executes via the plurality of geographically distributedcomputer systems in the peer-to-peer network, sixth authorizationinstructions to verify the sixth call came from an authorized contractaddress, and upon verification, to execute a seventh call request to thefifth contract address to obtain a sixth amount of digital asset tokenswhich reflect a current balance of digital asset tokens associated withthe first designated public address. In embodiments, in response to theseventh call request, the fifth smart contract, executes via theplurality of geographically distributed computer systems in thepeer-to-peer network, the seventh call request to return the sixthamount of digital asset tokens In embodiments, in response to the returnof the sixth amount of digital asset, the fourth smart contractexecutes, via the plurality of geographically distributed computersystems in the peer-to-peer network: (1) a balance verificationinstruction to confirm that the fifth amount of digital asset tokens isless than or equal to the sixth amount of digital asset tokens, and (2)in the case where the fifth amount of digital asset tokens is less thanor equal to the sixth amount of digital asset tokens, execute, via theplurality of geographically distributed computer systems in thepeer-to-peer network, a seventh call request to the fifth contractaddress to set a new balance for the digital asset tokens in the firstdesignated public address to a seventh amount which equals the sixthamount less the fifth amount. In embodiments, in response to the seventhcall, the fifth smart contract executes, via the plurality ofgeographically distributed computer systems in the peer-to-peer network,the seventh call to set and store the new balance for the firstdesignated public address as the seventh amount and returns a newbalance for the first designated public address as the seventh amount.In embodiments, in response to the return of the new balance, the fourthsmart contract executes, via the plurality of geographically distributedcomputer systems in the peer-to-peer network, an eighth call to add thesecond amount of digital asset tokens to the balance associated with thethird designated public address. In embodiments, in response to theeighth call request, the fifth smart contract executes, via theblockchain network, the eighth call request to set the balance ofdigital asset tokens associated with the third designated public addressat a seventh amount which includes the addition of the second amount toa previous balance associated with the third designated public address;and wherein the first user device confirms that the balance of digitalasset tokens associated with the first designated public address is thesixth amount of digital asset tokens based on reference to theblockchain.

In embodiments, the second transaction request includes secondtransaction fee information for miners in the plurality ofgeographically distributed computer systems in the peer-to-peer networkto process the second transaction request. In embodiments, the balanceof digital asset tokens associated with the third designated publicaddress is returned to the fourth contract address. In embodiments, thebalance of digital asset tokens associated with the third public addressis returned to the first smart contract address. In embodiments, asecond user device confirms that the balance of the digital asset tokensassociated with the third designated public address is the seventhamount of digital asset tokens based on reference to the blockchain.

In embodiments, the process of increasing the total supply of digitalasset tokens further includes providing a third designated key set,including a third designated public address associated with theunderlying digital asset and a corresponding third designated privatekey, and wherein the third designated private key is stored on a thirdcomputer system which is connected to the distributed public transactionledger through the Internet.

In embodiments, the process continues with receiving, by the pluralityof geographically distributed computer systems in the peer-to-peernetwork, from the third computer system, via the blockchain, a secondtransaction request: (A) from the third designated public key address;(B) to the fifth contract address; and (C) including a second messageincluding a request to burn a fifth amount of digital asset tokens froma balance associated with the third designated public address. Inembodiments, the second transaction request is digitally signed by thethird designated private key. In embodiments, the fourth smart contractexecutes, via the plurality of geographically distributed computersystems in the peer-to-peer network, the second transaction request toexecute, via the plurality of geographically distributed computersystems in the peer-to-peer network, a sixth call request to the fifthcontract address to obtain a sixth amount of digital asset tokens whichreflect a current balance of digital asset tokens associated with thethird designated public address. In embodiments, in response to thesixth call request, the fifth smart contract, executes via the pluralityof geographically distributed computer systems in the peer-to-peernetwork, the seventh call request to return the sixth amount of digitalasset tokens; wherein, in response to the return of the sixth amount ofdigital asset, the fourth smart contract executes, via the plurality ofgeographically distributed computer systems in the peer-to-peer network:(1) a balance verification instruction to confirm that the fifth amountof digital asset tokens is less than or equal to the sixth amount ofdigital asset tokens; and (2) in the case where the fifth amount ofdigital asset tokens is less than or equal to the sixth amount ofdigital asset tokens, execute, via the plurality of geographicallydistributed computer systems in the peer-to-peer network, a seventh callrequest to the fifth contract address to set a new balance for thedigital asset tokens associated with the third designated public keyaddress to a seventh amount which equals the sixth amount less the fifthamount. In embodiments, in response to the seventh call, the fifth smartcontract executes, via the plurality of geographically distributedcomputer systems in the peer-to-peer network, the seventh call to setand store the new balance for the third designated public key address asthe seventh amount and returns the new balance for the third designatedpublic key address as the seventh amount. In embodiments, in response tothe return of the new balance, the fourth smart contract executes, viathe blockchain network, an eighth call request to the fifth contractaddress to obtain a total supply of digital asset tokens in circulation.In embodiments, in response to the eighth call request, the fifth smartcontract executes, via the plurality of geographically distributedcomputer systems in the peer-to-peer network, the eighth call requestand returns, to the fourth contract address, an eighth amount of digitalasset tokens corresponding to the total supply of digital asset tokensin circulation. In embodiments, in response to the return of the eighthamount, the fourth smart contract, executes via the plurality ofgeographically distributed computer systems in the peer-to-peer network,a ninth call request to the fifth contract address to set a new totalsupply of digital asset tokens in circulation to a ninth amount, whichis the eighth amount less the fifth amount. In embodiments, in responseto the ninth call request, the fifth smart contract, executes via theblockchain network, the ninth call request and sets a new total supplyof digital asset tokens in circulation at the ninth amount, and returnsto the fourth contract address.

In embodiments, the third designated key set is the first designated keyset. In embodiments, the third designated key set is not the seconddesignated key set. In embodiments, the third designated key set is thesecond designated key set. In embodiments, the third designated key setis not the first designated key set. In embodiments, the third computersystem is the first computer system. In embodiments, the third computersystem is not the first computer system. In embodiments, theadministrator computer system (e.g. Administrator 1801) includes thefirst computer system and the third computer system. In embodiments, theadministrator computer system includes the first computer system and thesecond computer system.

In embodiments, the underlying digital asset is a stable value token. Inembodiments, the underlying digital asset is Neo. In embodiments, theunderlying digital asset is Ether. In embodiments, the underlyingdigital asset is Bitcoin.

In embodiments, the first designated private key is mathematicallyrelated to the first designated public key.

In embodiments, wherein the first designated public address includes thefirst designated public key.

In embodiments, the first designated public address includes a hash ofthe first designated public key.

In embodiments, the first designated public address includes a partialhash of the first designated public key.

In embodiments, the second designated private key is mathematicallyrelated to a second designated public key.

In embodiments, the second designated public address includes the seconddesignated public key.

In embodiments, the second designated public address includes a hash ofthe second designated public key.

In embodiments, the second designated public address includes a partialhash of the second designated public key.

In embodiments, the second smart contract instructions include sixthauthorization instructions related to modifying a token supply of thedigital asset token.

Holding Collateral in a Smart Contract on an Underlying Blockchain

FIG. 24 illustrates a schematic drawing of an exemplary network forholding collateral in a smart contract on an underlying blockchain inaccordance with exemplary embodiments of the present invention. Thenetwork shown in FIG. 24 may include a security token administratorsystem 6801 associated with an issuer of a security token 6805 (SecurityToken), a stable value token administrator system 6809 associated withan issuer of a stable value token 6807 (SV Coin Token), and a pluralityof end user devices 105 a, 105 b, . . . 105N, each associated one ormore corresponding end users. In embodiments, more than one end userdevice may be associated with the same end user.

In embodiments, each of systems 6801, 8609 and user devices 105 a, 105 b. . . 105N may communicated with and/or among each other directly and/orindirectly, e.g., through a data network 15, such as the Internet. Inembodiments, encryption and/or other security protocols may be used. Inembodiments, data network 15, may be a wide area network, a local areanetwork, a telephone network, dedicated access lines, a proprietarynetwork, a satellite network, a wireless network, a mesh network, orthrough some other form of end-user to end-user interconnection, whichmay transmit data and/or other information. Any participants in adigital asset network may be connected directly or indirectly, asthrough the data network 15, through wired, wireless, or otherconnections.

In embodiments, issuer of the security token may be one or moreentities. In embodiments, the issuer of the stable value token may beone or more entities. In embodiments, the issuer of the security tokenand the issuer of the stable value token may be the same or differententity. In embodiments, one or more administrators may operate thesecurity token administrator system 6801 on behalf of the issuer of thestable value token. In embodiments, the same or different administratorsmay operate the stable value token administrator system 6809. Inembodiments, the issuers and/or administrators may be a trust company, aregulated trust company, a bank, a broker dealer, or some other form ofentity, to name a few.

In embodiments, the administrator system 6801 may access one or moredatabases stored on non-volatile computer readable memory includingcontract parameters data base 6801B, key information data 6801C andsmart contract information 6801D. As further illustrated in FIG. 25A, inembodiments, contract parameters database 6801B may include at least thefollowing smart contract terms or attributes: (1) inception date data6902; (2) inception value data 6904; (3) benchmark data 6906; (4)contract duration data 6908; (5) collateral requirements data 6910; and(6) notional value data 6912, to name a few. In embodiments, othercontract parameters may be stored in the contract parameters database.Additional databases, to name a few, are discussed above in connectionwith FIGS. 6A, 10, 26, 29, 30E, 57, 60, 61A, 61B, and 65C-1-2. Moreover,additional databases may include the databases discussed above inconnection with the descriptions of Blockchain Financial Instruments,Digital Asset Exchanges, and Digital Wallets, to name a few. Inembodiments, inception date data 6902 may refer to data that indicatesdates at which smart contracts actually begin. In embodiments, inceptionvalue data 6904 may refer to data that indicates a value of smartcontracts at a corresponding inception date. Benchmark data 6906 mayrefer to data that indicates benchmark information of which smartcontracts are based off. In embodiments, contract duration data 6908 mayrefer to durations of smart contracts. In embodiments, collateralrequirements data 6910 may refer to specific collateral requirements forsmart contracts. In embodiments, notional value data 6912 may refer tothe total amount of a security's underlying asset at its spot price inreference to smart contract values.

As illustrated in FIG. 24, the administrator system 6801, stable valueadministrator 6809, and/or user devices 105 a, 105 b and/or 105N maycommunicate with a blockchain network to access and/or add blocks toblockchain 6803. The blockchain 6803 may include one or more tokens,such as Security Token 6805 and SVCoin Token 6807 as illustrated. Eachtoken will have at least one corresponding smart contract address (e.g.,smart contract address 6805A for Security Token 6805, and smart contractaddress 6807A for SVCoin Token 6807, to name a few) by whichinstructions for each token may be accessed. In embodiments, the smartcontract address may be associated with a proxy smart contract which maythen issue calls to one or more other smart contracts having their ownsmart contract addresses.

As illustrated in FIG. 25B, a security token smart contract 6805B isprovided on the underlying blockchain 6803. Security token 6805 may alsoinclude a plurality of instruction modules that collectively make up thesmart contract associated with the security token. By way ofillustration, in embodiments, such modules may include modules ofinstructions such as: (1) a create security tokens module 6918; (2) atransfer tokens module 6920; (3) a destroy security tokens module 6922;(4) an access data module 6924; (5) an authorize instructions module;(6) a calculate excess collateral module 6928; (7) a generate collateralinformation message module 6930; and (8) a send collateral informationmessage module, to name a few.

In embodiments, the create security token module 6918 may include one ormore authorization instructions related to creating security tokens.Such instructions may specify one or more authorized key pairs orcontract addresses that may be authorized to create security tokensunder specified conditions. In embodiments, the create security module6918 may include instructions on increasing the token supply. Inembodiments, the create security token module 6918 may includeinstructions on how to create new tokens within pre-approved tokensupply limits and how to assign newly created or “minted” tokens tospecific designated public addresses or contract addresses on theunderlying blockchain.

In embodiments, the transfer tokens module 6920, in embodiments, mayinclude authorization instructions related to transferring securitytokens. In embodiments, such transfer instructions may include rules bywhich certain transfer are allowed or blocked and may specify one ormore key pair or contract addresses that may be authorized to performone or more types of transfer operations. In embodiments, the transfertokens module 6920 may include authorization instructions related totransferring stable value tokens to smart contract address 6805A. Inembodiments, the transfer tokens module 6920 may include authorizationinstructions related to transferring stable value tokens from smartcontract address 6805A.

In embodiments, the destroy security tokens module 6922 may includeauthorization instructions related to destroying security tokens,including, in embodiments, instructions on when, and with whoseauthority, security tokens associated with one or more specifiedaddresses shall be destroyed or “burned”, and thus removed from thesecurity token supply.

The access data module 6924, in embodiments, may include authorizationinstructions related to accessing data supplied by a first authorizedthird party database (i.e. administrator system 6801), as discussed infurther detail elsewhere.

The authorize instructions module 6926 may further include instructionsto authorize the transfer of stable value tokens from the secondcontract address 6805B.

The generate collateral information message module 6930, in embodiments,may include instructions to generate a collateral confirmation messageto the administrator system 6801 confirming receipt of at least one of afirst amount of collateral and a second amount of collateral when atleast one of the first amount of collateral and the second amount ofcollateral is received.

In embodiments, the send collateral information message module 6932 mayinclude instructions to send the collateral confirmation message to theadministrator system 6801 confirming receipt of at least one of a firstamount of collateral and a second amount of collateral when at least oneof the first amount of collateral and the second amount of collateral isreceived.

As illustrated in FIG. 25C, a stable value token smart contract 6807B isprovided on the underlying blockchain 6803. Stable value token 6807 mayalso include a plurality of instruction modules that collectively makeup the smart contract associated with the stable value token. By way ofillustration, in embodiments, such modules may include modules ofinstructions such as: (1) a create stable value token module 6934; (2) atransfer stable value token module 6936; (3) a destroy stable valuetoken module 6938; and (4) authorization instruction module.

In embodiments, the create stable value token module 6934 may includeauthorization instructions related to creating stable value tokens.

The transfer stable value token module 6936, in embodiments, may includeauthorization instructions related to transferring stable value tokens.

In embodiments, the destroy stable value token module 6938 may includeauthorization instructions related to destroying stable value tokens.

In embodiments, the authorization instruction module 6940 may includeauthorization instructions related to functions associated with thestable value tokens. In embodiments, authorization instructions module6940 may also include instructions to authorize request received, therequests, in embodiments, being transaction requests fromadministrators, user public addresses, or other smart contracts.

While security token 6805 is described as a security token, inembodiments, the security token may reflect other types of tokens, suchas tokens associated with a security, a bond, a financial instrument, acontract, and stock, to name a few. Similarly, while the SVCoin token6807 is describe a stable value token, in embodiments, the SVCoin token6807, may reflect other kinds of token which may not necessarily reflecta stable value, e.g., Gas tokens, and/or some other kind of token whichthe parties to the transaction reflect as an appropriate collateral.

Referring to FIG. 28, an exemplary process for generating a smartcontract in accordance with an embodiment of the present application isprovided. In embodiments, the process shown in FIG. 28 may begin at astep S7302. In step S7302, an administrator system (i.e. administratorsystem 6801) may receive a contract request. In embodiments, thecontract request may be received from a first user, and includes useridentification information and a request to generate a smart contract.In embodiments, the first user may be an individual, associated with afirst user device. In embodiments, the user identification informationmay be associated with the first user. In embodiments, the useridentification information may be associated with a first user device.In embodiments, the first user may not be an individual, but may be anorganization or entity such as a financial institution, exchange orbrokerage house, to name a few. In embodiments, the first user devicemay be associated with a financial institution, exchange or brokeragehouse, to name a few. In embodiments, the first user device may be Userdevice 105 a. The contract request, in embodiments, may also include asmart contract generation request. The smart contract generationrequest, in embodiments, is a request from a user device, associatedwith a first user, to an administrator system to generate a smartcontract.

In embodiments, a contract request may be from more than one user. Inembodiments, a first user and second user may agree in advance, as tocontract parameters, and one or the other may send a contract requestthat includes first user identification information associated with afirst user device that is associated with a first user as well as secondused identification information associated with a second user devicethat is associated with a second user. The first user device, inembodiments, may be User device 105 a. In embodiments, the second userdevice may be User device 105 b. The contract request, in embodiments,may include a smart contract generation request. The smart contractgeneration request, in embodiments, is a request from a user device toan administrator system to generate a smart contract.

In embodiments, the contract request may be for a contract where theparameters are already agreed upon by more than two users (i.e. Userdevice 105 a, User device 105 b, . . . User device 105 n). For example,where the contract parameters are already agreed upon by more than twousers, the contract request may include user information for each of theusers of which have already agreed upon the parameters of the requestedcontract. The contract request, in embodiments, may also include a smartcontract generation request.

Once a contract request is received by the administrator system, at stepS7304, the administrator system may generate graphical user interface(GUI) information including at least one prompt for the first user toprovide contract parameters related to the smart contract to begenerated. In embodiments, the administrator system may also generateGUI information that prompts a user to input information correspondingto the contract parameters similar to or the same as the publishedcontracts parameters described in connection with FIGS. 71A-71B (i.e.inception date 7104, inception value 7106, benchmark data 7108, contractduration data 7110, collateral requirement 7112, notional value 7114,early termination rules 7130, and second benchmark data 7132, to name afew) and the contract parameters of contract parameters data base 6801Bdescribed in connection with FIG. 25A, the descriptions of whichapplying herein. In embodiments, the administrator system may generategraphical user interface (GUI) information including at least one promptfor the second user to provide contract parameters related to the smartcontract to be generated.

Once the GUI information is generated, at step S7306, the administratorsystem may send the GUI information to the first user device. Inembodiments, once received by the first user device, the first userdevice may use the GUI information to display a GUI. In embodiments,such as embodiments where the contract parameters are already agreedupon by more than one user, the administrator system may send the GUIinformation to the first user device and the second user device. Inembodiments, once received, the first and second user devices may eachuse the GUI information to display a GUI. In embodiments, such asembodiments where the parameters are already agreed upon by more thantwo users, the administrator system may send the GUI information to morethan two user devices. In embodiments, once received, the more than twouser devices may each use the GUI information to display a GUI.

In embodiments, once the GUI information is received by the first userdevice, the first user device may receive one or more inputs which mayinclude contract information including the contract parameters. Forexample, the user device may receive inputs that indicate an inceptiondate 7104, inception value 7106, benchmark data 7108, contract durationdata 7110, collateral requirement 7112, notional value 7114, earlytermination rules 7130, and second benchmark data 7132, to name a few.In embodiments, where the GUI information is sent to more than onedevice, for example, where the GUI information is sent to a first userdevice and a second user device, at least one of the user devices mayreceive inputs which may include contract information including thecontract parameters. The contract information including the contractparameters may, in embodiments, be sent from the first and or seconduser devices to the administrator system.

At a step S7308, the administrator system may receive, from the firstuser device, in response to the at least one prompt included in thegraphical user interface information, contract information including thecontract parameters of the contract to be generated. In embodiments,such as embodiments where the contract parameters are already agreedupon by more than one user, the administrator system may receivecontract information including the contract parameters of the contractto be generated from at least one of the first user device and thesecond user device. In embodiments, such as embodiments where theparameters are already agreed upon by more than two users, theadministrator system may receive contract information including thecontract parameters of the contract to be generated from at least one ofthe user devices associated with the users that have already agreed uponthe contract parameters.

Once the contract information is received by the administrator system,at a step S7310, the administrator system may store the contractinformation including the contract parameters in memory operablyconnected to the administrator system. In embodiments, the contractinformation may be stored in smart contract information database 6801D.

In embodiments, the contract parameters provided in the processdescribed in connection with FIG. 28 may be used in arranging formultiple transactions based on the contract parameters. In embodiments,the contract parameters that are provided by the first user device, forexample, may published to a plurality of user devices, in the samemanner as is described below with respect to step S7002. In this case,users may indicate their desire to participate in the contractconsistent with step S7004 discussed below.

The steps of the process described in connection with FIG. 28 may berearranged or omitted.

In embodiments, the process of FIG. 28 may continue with the process inFIG. 26A. In alternative embodiments, FIG. 26A may be its own process,beginning with step S7002. Referring to FIG. 26A, In step S7002, anadministrator system 6801 may publish (via, e.g. a public or privatewebsite or mobile application) a contract having contract parameters.Contract parameters, as described in step S7002 may be retrieved fromcontract parameters database 6801B. In embodiments, as shown in FIG.25A, contract parameters database 6801B as discussed before. Thepublished contract, in embodiments, may have a graphical user interface(GUI), including such information as shown in connection with FIG. 27A.The published contract may show some or all of the data describedearlier in connection with FIG. 25A. For example, as shown in FIG. 27A,the published contract 7102 may have (1) an inception date 7104 of Jul.19, 2018; (2) an inception value 7106 of $10,000; (3) benchmark data7108 from the S&P 500; (4) a contract duration 7110 of 5 days; (5) acollateral requirement 7112 of 100 Stable Value Coins; and (6) anotional value 7114 of $10,000. Other values and parameters may beincluded consistent with embodiments of the present invention. Inembodiments, these other values and parameters may include informationthat may be used to determine the contract parameters discussed above,and/or other parameters including: (1) asset identification information;(2) a current (spot) price; (3) a type of derivative; (4) a side(buy/sell); (5) a call/put designation, (6) an expiration date or term,(7) a strike price; (8) pricing model information, and (10) volatilityinformation, to name a few. In embodiments, user input of certaininformation may prompt requests for additional information. In oneexample, input of an identification of a particular type of derivativemay require user identification of other information, such as upper orlower price limit, to name a few.

In embodiments, the type of derivative may be any one of: vanilla, fxhedge, flexi forward, knock out, knock in, double knockout, double knockin, no touch, one touch, double no touch, double one touch, digital,digital knockout, digital knockin, digital double knockout, digitaldouble knockin, compound, sequential—kiko & kiki, koki—no sequential,digital sequential, average (Asian), fader, digital accrual, accrual,accumulator, accumulator KO, accumulator KI, cas, dcd vanilla, dcdknockout, dcd knockin, average forward, euro-american KO, targetredemption forward, dual-strike tarf, kockin tarf, pivot tarf, varianceswap, volatility swap and forward volatility agreement, to name a few.

In embodiments, the pricing model may be any one of: black-scholes,vanna-volga, heston, local vol, stoch-local vol, stochastic, to name afew.

In embodiments, the smart contract parameters database may furtherinclude: (7) early termination rule data 6914; and (8) second benchmarkdata 6916, to name a few. In embodiments, early termination rule data6914 may include rules that charge a fee associated with a userterminating the smart contract before the contract duration iscompleted. Second benchmark data 6916 in some embodiments may bedifferent than benchmark data 6906. The published contract, inembodiments, may include a GUI with such information as shown inconnection with FIG. 27B. In embodiments, the published contract mayshow some or all of the data described earlier in connection with FIG.25A. For example, as shown in FIG. 27B, the published contract 7116 mayhave (1) an inception date 7118 of Jul. 20, 2018; (2) an inception value7120 of $1,000; (3) benchmark data 7122 from the S&P 500; (4) a contractduration 7124 of 2 days; (5) a collateral requirement 7126 of 10 StableValue Coins; (6) a notional value 7128 of $1,000; (7) no earlytermination rules 7130; and (8) second benchmark data 7132 fromWinkdex®. While there are no early termination rules shown in thepublished contract of FIG. 27B, early termination rules may include, forexample, a fee for terminating the contract early. Other values andparameters may be included consistent with embodiments of the presentinvention.

Referring to FIG. 26A, In step S7004, the administrator system 6801 mayreceive a plurality of indications of interest (“IOIs”) or bids fromusers. Referring to FIGS. 27C-27F, the IOIs may include at least a firstindication of interest (e.g. first indication of interest 7134 describedin connection with FIG. 27C or first indication of interest 7140described in connection with FIG. 27D) and a second indication ofinterest (e.g. second indication of interest 7150 described inconnection with FIG. 27E or second indication of interest 7156 describedin connection with FIG. 27F). In embodiments, the first indication ofinterest may be a first user response sent from a first user device 105a to administrator system 6801. In embodiments, the first user device105 a may be associated with a first user (e.g. Alice). In embodiments,as illustrated in FIGS. 71C and 71D, the first indication ofinterest7134, 7140 may include at least first user identificationinformation 7136, 7142 associated with the first user (e.g., a name,user number, email address, to name a few used to identify theindication of interest as coming from the first user (Alice)), and firstside information 7138, 7144 (e.g., buy). First side information mayinclude identification of a first leg of the smart contract (e.g., buyor sell). In embodiments, additional information, such as shown in FIG.27D may also be included in an indication of interest. For example,referring to FIG. 27C, a first indication of interest 7134 may be sentby Alice (as the first user) to Gemini (as the security tokenadministrator). Alice's indication of interest 7134 may include her useridentification number 7136, ID No. 12345 (as the first useridentification information), and information indicating that Alice wouldlike to buy 7138 (as the first side information).

In embodiments, the first indication of interest may further includeadditional information such as, a first user public address and/or firstcollateral information, to name a few. In embodiments, such additionalinformation may not be necessary to include in the indication ofinterest because it may be included in the contract parameters aspublished and thus implied. First collateral information may be instable value digital asset tokens (SVCoins). For example, referring toFIG. 27D, a first indication of interest 7140 may be sent by Alice (as afirst user) to Gemini (as the security token administrator). Alice'sindication of interest may include: (1) her user identification number7142, ID No. 12345 (as the first user identification information); (2)information indicating that Alice would like to buy 7144 (as the firstside information); Alice's Public Address 7146 (as the a first userpublic address); and (4) information indicating a collateral 7148 of 100Stable Value Coins (as the first collateral information).

In embodiments, the second indication of interest may be a second userresponse sent from a second user device 105 b to administrator system6801. In embodiments, the second user device 105 b may be associatedwith a second user (e.g. Bob). The second indication of interest (e.g.second indication of interest 7150 described in connection with FIG. 27Eor second indication of interest 7156 described in connection with FIG.27F) may include second user identification information 7152, 7158associated with the second user (e.g. a name, user number, emailaddress, to name a few used to identify the indication of interest ascoming from the second user (Bob), and second side information (e.g.sell). The second side information may include identification of asecond leg of the smart contract (e.g. buy or sell). In embodiments, thesecond leg is different from the first leg. In embodiments, additionalinformation, such as shown in FIG. 27F, may also be included in anindication of interest. For example, referring to FIG. 27E, a secondindication of interest 7150 may be sent by Bob (as the second user) toGemini (as the security token administrator). Bob's indication ofinterest 7150 may include his user identification number 7152, ID No.54321 (as the second user identification information), and informationindicating 7154 that Bob would like to sell (as the first sideinformation). In some embodiments, the second indication of interest myfurther include additional information such as, a second user publicaddress 7162 and/or second collateral information 7164, to name a few.The second collateral information 7164 may be in stable value digitalasset tokens (“SVCoins”). In embodiments, the second indication ofinterest may include the second user's digital signature which is basedon their private key which corresponds to their public key which isassociated with their public address. For example, referring to FIG.27F, a second indication of interest 7156 may be sent by Bob (as thesecond user) to Gemini (as the security token administrator). Bob'sindication of interest 7156 may include: (1) his user identificationnumber 7158, ID No. 54321 (as the second user identificationinformation) or Alice's digital signature which is based on her privatekey which corresponds to her public key which is associated with herPublic Address; (2) information indicating that Bob would like to sell7160 (as the second side information); Bob's Public Address 7162 (as thesecond user public address); and (4) information indicating a collateral7164 of 100 Stable Value Coins (as the second collateral information).In embodiments, Bob's indication of interest may include the Bob'sdigital signature which is based on Bob's private key which correspondsto Bob's public key which is associated with Bob's Public Address.

In embodiments, step S7004 may further include the administrator systemmay receive a third and fourth user responses from a fourth user deviceand a fifth user device, for example. The third user response, in someembodiments, may include fourth user identification informationassociated with the fourth user. In embodiments, the third user responsemay also include third side information comprising identification of thefirst leg of the contract. In embodiments, the third user response maybe similar to first indication of interest 7134 described in connectionwith FIG. 27C, first indication of interest 7140 described in connectionwith FIG. 27D, second indication of interest 7150 described inconnection with FIG. 27E and/or second indication of interest 7156described in connection with FIG. 27F, the descriptions of whichapplying herein.

The fourth user response may include fifth user identificationinformation associated with the fifth user. In embodiments, the fourthuser response may also include fourth side information comprisingidentification of the second leg of the contract, the fourth sideinformation being different than the third side information. Inembodiments, the fourth user response may be similar to first indicationof interest 7134 described in connection with FIG. 27C, first indicationof interest 7140 described in connection with FIG. 27D, secondindication of interest 7150 described in connection with FIG. 27E and/orsecond indication of interest 7156 described in connection with FIG.27F, the descriptions of which applying herein.

Referring back to FIG. 26A, after receiving the first user response(i.e. a first indication of interest) and the second user response (i.e.a second indication of interest), In step S7006, the administratorsystem 6801 matches the first user response with the second userresponse. For example, referring to FIGS. 27C-27F, administrator 6801may match Alice with Bob because Alice wants to buy and Bob would liketo sell. In embodiments, such as embodiments where more than one userhas agreed to the contract provisions in the published contract (asdiscussed above in connection with FIG. 28), matching may not berequired and step S7006 may be omitted.

In embodiments, such as the embodiments where a third user response andfourth user response are received by the administrator system, the thirduser response may be matched with the fourth user response.

In step S7008, a stable value token smart contract associated with astable token 6807 and first smart contract instructions 6807B associatedwith a first contract address 6807A associated with the blockchain 6803for the underlying digital asset are provided. In embodiments, the firstsmart contract instructions 6807B are saved in the blockchain 6803 forthe underlying digital asset. In embodiments, the first smart contractinstructions 6807B may include the stable value token smart contractinstructions 6807B described in connection with FIG. 25C, the samedescription applying herein.

Referring back to FIG. 26A, In step S7010, a security token smartcontract associated with a security token 6805 and second smart contractinstructions 6805B associated with the blockchain 6803 for theunderlying digital asset are provided. In embodiments, the second smartcontract instructions 6805B are saved in the blockchain 6803 for theunderlying digital asset. In embodiments, the second smart contractinstructions 6805B may include the security token smart contractinstructions 6805B described in connection with FIG. 25B, the samedescription applying herein.

In embodiments, step S7008 and step S7010 may be performed before stepS7002, step S7004, and step S7006.

Referring back to FIG. 26A, the process may continue with step S7012, inwhich the administrator system 6801 sets up a first trade (e.g.trade001) between the first user (e.g. the user associated with firstuser device 105 a) and the second user (e.g. the user associated withthe second user device 105 b) using the security token smart contract6805B on the underlying blockchain 6803 with collateral in the form ofstable value digital assets (i.e. stable value token 6807). Step S7012is described in more detail in connection with FIGS. 70B-D.

Referring to FIG. 26B, in embodiments, setting up the first tradebetween the first user and the second user may begin at step S7016,where the administrator system 6801 generates first trade instructionsfor the security token smart contract 6805B. The first tradeinstructions may include instructions to execute the first trade betweena first user public address associated with the first user (e.g. theuser associated with user device 105 a) and a second user public addressassociated with a second user (e.g. the user associated with user device105 b). In embodiments, the first trade is based at least on thecontract terms from step S7002 (i.e. one or more of the contractparameters discussed in connection with FIG. 25A), the first userresponse from step S7004 (associated with a received IOI—i.e. the IOI'sdescribed in connection with FIGS. 27C-27F), and the second userresponse from step S7004(associated with another received IOI—i.e. theIOI's described in connection with FIGS. 27E-27F).

In step S7018, the administrator system 6801 may generate first hashedtrade instructions, the first hashed trade instructions being generatedby applying a hash algorithm to the first trade instructions. Examplesof hash algorithms include MD 5, SHA 1, SHA 256, RIPEMD, and Keccak-256to name a few. Hash algorithms take an input of any length and create anoutput of fixed length, allowing the trade instructions to be detectableand usable by administrators and users on the underlying blockchain.However, applying a hash algorithm is not always necessary if tradeinstructions are published ahead of time

In step S7020, the administrator system 6801 sends a first transactionrequest from an administrator public address associated with theadministrator system 6801 to the second contract address 6805A via theunderlying blockchain 6803. In embodiments, the first transactionrequest, includes a first message which may include: (1) the firsthashed trade instructions; (2) a request to assign a first tradeidentification to a first trade associated with the hashed tradeinstructions. In embodiments, the first message may include requests toassign a first trade identification to the first trade associated withthe hashed trade instructions and include the first trade identificationassociated with the first hashed trade instructions. In embodiments, thefirst transaction request may further include first transaction feeinformation. The first transaction fee information, in embodiments, maybe for miners on the blockchain 6803 to process the first transactionrequest. The first transaction request may also be electronically signedby an administrator private key. The administrator private key may bemathematically related to the administrator public address.

The process may continue with step S7022. In step S7022, theadministrator system 6801 obtains the first trade identification of thefirst trade. In embodiments, the administrator system 6801 may determinethe first trade identification, as calculated by the security tokensmart contract, by monitoring transactions on the blockchain 6803 (asshown in connection with a step S7024 of FIG. 26B). In response toobtaining the first trade identification of the first trade, theadministrator system 6801 may notify the first user (e.g. the userassociated with user device 105 a) and the second user (e.g. the userassociated with user device 105 b) of the first trade identification. Instep S7026, the administrator system 6801 may send the first tradeidentification to the first user device 105 a associated with the firstuser. Similarly, in step S7028, the administrator system 6801 sends thefirst trade identification to the second user device 105 b associatedwith the second user.

In embodiments, as shown In step S7030, the first user device 105 a maysend a second transaction request from a first user public address (thefirst user public address being associated with the first user and thefirst user device 105 a) to the first contract address 6807A via theunderlying blockchain 6803. The second transaction request may include asecond message, the second message including requests to the stablevalue token smart contract 6807B regarding a first transfer of a firstamount of collateral. In embodiments, the second message may include thefirst trade information. In embodiments, the second transaction requestmay include second transaction fee information. The second transactionfee information may be for miners on the blockchain 6803 to process thesecond transaction request. In embodiments, the second message may alsoinclude a transfer request to the stable value smart contract totransfer the first amount of collateral in the form of stable valuedigital asset tokens 6807 from the first user public address to thesecond contract address 6805A. The transfer request, in embodiments,will be executed upon receipt of a first collateral request from thesecond contract address 6805A. In embodiments, the transfer requestincluded in the second message may be executed upon receipt of a firstcollateral request from the administrator system 6801. The secondtransaction request is also electronically signed by a first userprivate key. The first user private key may be mathematically related tothe first user public address.

In embodiments, the process described in FIG. 26B may continue with theprocess shown in connection with FIG. 26C. In embodiments, as shown Instep S7032, the second user device may send a third transaction requestfrom a second user public address (associated with the second user andthe second user device 105 b) to the second contract address 6805A viathe underlying blockchain 6803. The third transaction request mayinclude a third message including a second transfer request to thestable value token smart contract 6807B regarding a second transfer ofthe second amount of collateral from the second user public address tothe second contract address 6807A. In embodiments, the third transactionrequest may further include third transaction fee information. The thirdtransaction fee information, in embodiments, may be for miners on theblockchain 6803 to process the third transaction request. The secondtransfer request of the third message, in embodiments, will be executedupon receipt of a second collateral request from the second contractaddress 6805A. Alternatively, the second transfer request of the thirdmessage will be executed upon receipt of a second collateral requestfrom the administrator system 6801. The third transaction request mayalso be electronically signed by a second user private key. The seconduser private key may is mathematically related to the second user publicaddress.

The process may continue with a step S70121. In step S7034, theadministrator system 6801 monitors transactions of the stable valuedigital asset tokens 6807 on the blockchain 6803 to determine that thesecond contract address 6805A has received at least the following: (1)the first amount of collateral in stable value digital asset tokens fromthe first user (e.g. the user associated with user device 105 a); and(2) the second amount of collateral in stable value digital asset tokensfrom the second user (e.g. the user associated with user device 105 b).In embodiments, the administrator system 6801 may further monitor thefirst contract address 6807A to determine whether the first amount ofcollateral is received at the second contract address 6805A and whetherthe second amount of collateral is received at the second contractaddress 6805A (as shown in connection with a step S7036 of FIG. 26C andstep S7038 of FIG. 26C).

Alternatively, the administrator system 6801 may receive a collateralconfirmation message confirming that the first amount of collateral andthe second amount of collateral are received by the second contractaddress 6805A (as shown in connection with a step S7040 of FIG. 26C). Inembodiments, either the first amount of collateral, the second amount ofcollateral, or both may not be received at the second contract address.If either or both are not received, in embodiments, the collateralconfirmation message may indicate a lack of collateral, or thecollateral confirmation message may not be sent.

Upon determining that the first amount of collateral from the first user(e.g. the user associated with user device 105 a) and the second amountof collateral from the second user (e.g. the user associated with userdevice 105 b) have both been received by the second contract address6805A, In step S7042, the administrator system 6801 may send a fourthtransaction request from the administrator public address to the secondcontract address 6805A via the underlying blockchain 6803. The fourthtransaction request may include a fourth message including the firsttrade instructions and the first trade identification. In embodiments,the fourth transaction request may further include fourth transactionfee information. The fourth transaction fee information, in embodiments,may be for miners on the blockchain 6803 to process the fourthtransaction request. The fourth transaction request may also beelectronically signed by the administrator private key.

In embodiments, the second contract address 6805A may further includemodules with instructions to: (1) generate a first collateral requestwhen the third message is received by the second contract address 6805A;(2) send the first collateral request to the first contract address6807A associated with the stable value token smart contract; (3)generate a second collateral request when the third message is receivedby the first contract address 6807A; (4) send the first collateralrequest to the first contract address 6807A associated with the stablevalue digital asset token smart contract; confirming that the firstamount of collateral from the first user (e.g. a user associated withuser device 105 a) and the second amount of collateral from the seconduser (e.g. a user associated with user device 105 b) has been receivedby the second contract address; and (5) sending a collateralconfirmation message to the administrator public address.

Upon receiving the confirmation message, the administrator system 6801may send a fourth transaction request from the administrator publicaddress to the second contract address 6805A via the underlyingblockchain 6803. The fourth transaction message may include a fourthmessage comprising first trade instructions and the first tradeidentification.

Referring now to FIG. 26D, in embodiments, step S7012 may being with astep S7042. In step S7042, the administrator system 6801 may send afirst transaction request from the administrator public address to thesecond contract address 6805A via the underlying blockchain 6803. Thefirst transaction request, in embodiments, may include a first messagecomprising requests to create a first trade between the first user andthe second user in accordance with the security token smart contract6805B. In embodiments, the first transaction request may further includefirst transaction fee information. The first transaction feeinformation, in embodiments, may be for miners on the blockchain 6803 toprocess the first transaction request. The first transaction request mayalso be electronically signed by the administrator private key. Theadministrator private key is mathematically related to the administratorpublic address.

In embodiments, as shown In step S7044, the first user device 105 a maythen send a second transaction request from a first user public address(the first user public address being associated with the first user andthe first user device 105 a) to the first contract address 6807A via theunderlying blockchain 6803. The second transaction request may include asecond message, the second message authorizing the stable value tokensmart contract 6807B to accept a request to transfer a first amount ofcollateral from the first user public address to the second contractaddress 6805A. In embodiments, the second transaction request mayfurther include second transaction fee information. The secondtransaction fee information, in embodiments, may be for miners on theblockchain 6803 to process the second transaction request. The secondtransaction request may be electronically signed by the first userprivate key. The first user private key is mathematically related to thefirst user public address.

The process may continue at step S7046. At a step S7046, the second userdevice may send a third transaction request from a second user publicaddress (associated with the second user and the second user device 105b) to the second contract address 6805A via the underlying blockchain6803. The third transaction request may include a third messageauthorizing the stable value digital asset smart contract 6807B toaccept a request to transfer a second amount of collateral from thesecond user public address to the second contract address 6805A. Inembodiments, the third transaction request may further include thirdtransaction fee information. The third transaction fee information, inembodiments, may be for miners on the blockchain 6803 to process thethird transaction request. The third transaction request may beelectronically signed by the second user private key. The second userprivate key is mathematically related to the second user public address.

In step S7048, the administrator system 6801 may send a fourthtransaction request from the administrator public address to the firstcontract address 6807A via the underlying blockchain 6803. The fourthtransaction request may include a fourth message including requests to:(1) transfer of the first amount of collateral of stable value digitalasset tokens from the first user public address to the second contractaddress 6805A; and (2) transfer of a second amount of collateral ofstable value digital asset tokens 6807 from the second user publicaddress to the second contract address 6805A. The fourth transactionrequest may also be electronically signed by the administrator privatekey.

Alternatively, the second contract address 6805A may send a fourthtransaction request to the first contract address 6807A via theunderlying blockchain 6803. The fourth transaction request may similarlyinclude a fourth message including requests to: (1) transfer of thefirst amount of collateral of stable value digital asset tokens 6807from the first user public address to the second contract address 6805A;and (2) transfer of a second amount of collateral of stable valuedigital asset tokens from the second user public address to the secondcontract address 6805A.

In alternative embodiments, steps 57010 and 57012 (and accompanyingsubsteps described above in connection with FIGS. 70B-D) may be replacedby a method of generating the security token contract associated withthe security token 6805 associated with blockchain 6803 for theunderlying digital asset. The method, in embodiments, may begin by anadministrator 6801 generating the security token smart contractassociated with a security token 6805 and second smart contractinstructions 6805B associated with a second smart contract address 6805Aassociated with the blockchain 6803 for the underlying digital asset. Inembodiments, the second smart contract instructions 6805B are saved inthe blockchain 6803 for the underlying digital asset.

The second smart contract instructions 6805B may include one or more ofthe following: (1) first trade instructions for the security token smartcontract; (2) fifth authorization instructions regarding transferringsecurity tokens (which may be included in the transfer security tokensmodule 6920); (3)sixth authorization instructions regarding destroyingsecurity tokens (which may be included in the destroy security tokensmodule 6922); (4) seventh authorization instructions regardingtransferring stable value tokens to the second contract address (whichmay be included in the authorize instructions module 6926); (5) eighthauthorization instructions regarding transferring stable value tokensfrom the second contract address (which may be included in the authorizeinstructions module 6926); (6) calculating instructions regardingcalculating excess collateral(which may be included in the calculateexcess collateral module 6928); (7) generating collateral informationinstructions regarding excess collateral (which may be included in thegenerate collateral information message module 6930); and (8) sendingcollateral information message instructions regarding excess collateral(which may be included in the send collateral information message module6932). In embodiments, the first trade instructions may includeexecution instructions to execute a first trade between the first userand the second user. The first trade, in embodiments, may be based on atleast (1) the contract request or proposal and (2) the first userresponse.

In embodiments, once the security token contract is generated by anadministrator 6801, the administrator 6801 may send the security tokensmart contract and associated second smart contract instructions 6805Bto the second smart contract address 6805A via the blockchain 6803 forthe underlying digital asset.

In embodiments, the first trade instructions may be implemented via theblockchain 6803 for the underlying digital asset by computers systemsamong the plurality of geographically distributed computer systems inthe peer-to-peer network.

Referring back to FIG. 26A, the process of FIG. 26A may continue withstep S7014. In step S7014, excess collateral from the first trade may becollected from the security token contract. Step S7014 is described inmore detail in connection with FIGS. 70E-F.

Referring to FIG. 26E, in embodiments, collecting excess collateral maybegin at step S7050. In step S7050, the administrator system 6801 maysend a fifth transaction request from the administrator public addressto the second contract address 6805A via the underlying blockchain 6803.In embodiments, the fifth transaction request may include a fifthmessage comprising requests for the security token smart contract 6805Bto determine and distribute excess collateral for the first trade inaccordance with the security token smart contract 6805B and the firsttrade instructions. The fifth transaction request may be electronicallysigned by the administrator private key. The administrator private keyis mathematically related to the administrator public address.

In response to the requests contained in the fifth message, as shown instep S7052, the security token smart contract 6805B sends a sixthtransaction request from the second contract address 6805A to an oracleaddress associated with an oracle smart contract on the blockchain 6803associated with an oracle interface in contact with a trusted thirdparty database. The sixth transaction request, in embodiments, mayinclude a sixth message to obtain first benchmark data from the trustedthird party database. In response to sending the sixth transactionrequest, in step S7054, the security token smart contract 6805B mayreceive a callback message from the oracle interface including the firstbenchmark information. In embodiments, access to the trusted third partydatabase through the oracle smart contract may be limited to certainauthorized or approved addresses on the blockchain. In embodiments, asdescribed further below, a whitelist of authorized (or approved)requesting addresses may be provide in which the first benchmarkinformation is provided only in response to requests from an authorizedaddress. In embodiments, the whitelist of authorized requestingaddresses may be updated. In embodiments, the administrator system mayupdate the whitelist of authorized requesting addresses to reflect theaddress of the security token contract that is provided using theprocess of the present application.

In embodiments, the whitelist of authorized addresses may be included atthe oracle smart contract address. In embodiments, the oracle smartcontract address may include authorization instructions to request thefirst contract address only when the requester address is one of theaddresses on the whitelist. In embodiments, the oracle smart contractmay include authorization instructions related to an update key pair forupdating the whitelist of authorized addresses to allow for the whitelist to be updated.

In embodiments, the whitelist of authorized addresses may be provided inmemory element associated with the trusted third party database. Inembodiments, the trusted third party database will not provide the firstbenchmark information to the oracle contract unless the requesteraddress is included in the whitelist of authorized addresses.

In response to receiving a callback message, in step S7056, the securitytoken smart contract 6805B executes instructions to: (1) store the firstbenchmark information and (2) calculate the excess collateral for thefirst user (e.g. the user associated with user device 105 a) and thesecond excess collateral for the second user (e.g. the user associatedwith user device 105 b) by using the first trade instructions and thefirst benchmark information. In embodiments, the first excess collateralis the first amount of collateral less the difference between the firstbenchmark information and the inception value, to the extent it isgreater than zero. In embodiments, the second excess collateral is thesecond amount of collateral less the difference between the inceptionvalue and the first benchmark information, to the extent it is greaterthan zero.

To the extent that the first excess collateral is greater than zero orthe second excess collateral is greater than zero, in step S7058, thesecurity token smart contract 6805B sends a seventh transaction requestfrom the second contract address 6805A to the first contract address6807A via the underlying blockchain 6803. The seventh transactionrequest, in embodiments, may include a seventh message requesting thestable value token smart contract 6807B to transfer: (1) the firstexcess collateral in stable value digital asset token from the secondcontract address 6805A to the first user public address (associated withthe first user and user device 105 a), to the extent the first excesscollateral is greater than zero; and (2) the second excess collateral instable value digital asset token from the second contract address 6805Ato the second user public address (associated with the second user anduser device 105 b).

Referring to FIG. 26F, in embodiments, collecting excess collateral maybegin at step S7060 where an oracle service sends a fifth transactionrequest from an oracle address associated with an oracle interface tothe second contract address 6805A via the underlying blockchain 6803. Inembodiments, the fifth transaction request may include a fifth messagecomprising first benchmark information. In response to receiving thefifth message, in step S7062 the security token contract 6805B executesinstructions to store first benchmark information.

The process in FIG. 26F may continue at step S7064. In step S7064, theadministrator system 6801 may send a sixth transaction request from theadministrator public address to the second contract address 6805A viathe underlying blockchain 6803. The sixth transaction request, inembodiments, may include a sixth message comprising requests to thesecurity token smart contract 6805B to determine and distribute excesscollateral for the first trade in accordance with the security tokensmart contract 6805B and the first contract instructions. The sixthtransaction request may also be electronically signed by anadministrator private key (located in key information data base 6801C ofFIG. 24). The administrator private key is mathematically related to theadministrator public address. In embodiments, the sixth transactionrequest may be sent by user device 105 a from the first user publicaddress (associated with a first user and user device 105 a) to thesecond contract address 6805A. In embodiments, where the sixthtransaction request is sent by user device 105 a, the sixth transactionrequest may also be electronically signed by a first user private key.The first user private key is mathematically related to the first userpublic address. Furthermore, in embodiments, the sixth transactionrequest may be sent by user device 105 b from the second user publicaddress (associated with a second user and user device 105 b) to thesecond contract address 6805A. In embodiments, where the sixthtransaction request is sent by user device 105 b, the sixth transactionrequest may also be electronically signed by a second user private key.The second user private key is mathematically related to the second userpublic address.

In response to the requests contained in the sixth message, in stepS7014′D, the security token smart contract 6805B executes instructionsvia the blockchain 6803 to calculate first excess collateral for thefirst user (e.g. a user associated with user device 105 a) and secondexcess collateral for the second user (e.g. a user associated with userdevice 105 b) using the first trade instructions and the first benchmarkinformation. In embodiments, the first excess collateral is the firstamount of collateral less the difference between the first benchmarkinformation and the inception value, to the extent it is greater thanzero. In embodiments, the second excess collateral is the second amountof collateral less the difference between the inception value and thefirst benchmark information, to the extent it is greater than zero.

To the extent that the first excess collateral is greater than zero orthe second excess collateral is greater than zero, in step S7014′E, thesecurity token smart contract 6805B sends a seventh transaction requestfrom the second contract address 6805A to the first contract address6807A via the underlying blockchain 6803. The seventh transactionrequest, in embodiments, may include a seventh message requesting thestable value token smart contract 6807B to transfer: (1) the firstexcess collateral in stable value token from the second contract address6805A to the first user public address (associated with the first userand user device 105 a), to the extent the first excess collateral isgreater than zero; and (2) the second excess collateral in stable valuetoken from the second contract address 6805A to the second user publicaddress (associated with the second user and user device 105 b). As instep S7014E, if there is excess collateral, the second contract address6805A sends the excess collateral to the user of which that excesscollateral belongs.

In embodiments, such as the embodiments where a third user response andfourth user response are received by the administrator system andmatched, the administrator system may set up a second trade between thefourth user and the fifth user. This process of setting up a tradebetween two users may be similar to the process described in connectionwith FIGS. 26B-26D, the same description applying herein.

In embodiments, the steps within the process described above inconnection with FIGS. 26A-26F may be rearranged or omitted.

In embodiments, a separate security token smart contract may begenerated and published to the underlying blockchain for each separatetrade.

For example, in embodiments, generating a security token smart contractbetween a first user and a second user may be implemented, in accordancewith the following example. In embodiments, generating a security tokensmart contract between a first user and a second user may begin with anadministrator system associated with an administrator 6809 of a securitytoken smart contract receiving a contract proposal. In embodiments, thesecurity token smart contract is maintained on a distributed publictransaction ledger maintained by a plurality of geographicallydistributed computer systems in a peer-to-peer network in the form of ablockchain 6803 of an underlying digital asset. In embodiments, theunderlying digital asset may be a digital math-based asset, Ether, orNeo, to name a few. In embodiments, the contract proposal includes:first user information associated with a first user device 105 a that isassociated with a first user; and first contract information includingat least the following contract parameters 6801B: an inception date6902; an inception value 6904; at least one benchmark 6906; a contractduration 6908; at least one collateral requirement 6910; a notionalvalue of the smart contract 6912; and first side information, includingidentification of a first leg of the contract (e.g. the side informationincluding a leg of a contract described in FIGS. 27C-27F—ref nos. 7138,7144, 7154, 7160 respectively). In embodiments, the first userinformation further includes a first user public address (e.g., AlicePublic Address 7146 described above in reference to FIG. 27D) associatedwith the blockchain 6803 of the underlying digital asset. Inembodiments, the first user public address corresponds to a first userprivate key that is mathematically related to the first user publicaddress. In embodiments, the first contract information further includesat least one of the following: derivative type information; earlytermination rules 6914; a second benchmark 6916; asset identificationinformation; pricing model information; and volatility information. Inembodiments, the first contract information further includes firstcollateral information in stable value tokens (e.g., 100 Stable ValueCoins 7148 described above in reference to FIG. 27D). In embodiments,the first contract information further includes second collateralinformation in stable value tokens. In embodiments, the first contractinformation includes first transaction fee information. In embodiments,the administrator system may generate graphical user interfaceinformation including at least one prompt for the first user to providethe contract proposal. The administrator system may then send thegraphical user interface information to the first user device. Inembodiments, the administrator system may then receive the contractproposal in response to the at least one prompt.

In embodiments, the method continues with the administrator systemreceiving at least one indication of interest (e.g., second indicationof interest 7150 described above in reference to FIG. 27E). Inembodiments, the at least one indication of interest includes at least afirst user response, from a second user device 105 b associated with asecond user. In embodiments, the first user response includes seconduser information associated with the second user. In embodiments, thesecond user information further includes a second user public address(e.g., Bob Public Address 7162) associated with the blockchain 6803 ofthe underlying digital asset. In embodiments, the second user publicaddress corresponds to a second user private key that is mathematicallyrelated to the second user public address. In embodiments, the firstuser response further includes second side information which may includean identification of a second leg of the contract (e.g. the sideinformation including a leg of a contract described in FIGS.27C-27F—reference numbers 7138, 7144, 7154, and 7160 respectively).

In embodiments, the method continues with the administrator systemmatching the first contract information and the first user response.Matching, by the administrator system, may be similar to S7006 of FIG.26A.

In embodiments, the method continues with an administrator systemproviding a stable value token smart contract associated with a stablevalue token 6807 and first smart contract instructions 6807B for adigital asset token. The digital asset token, in embodiments, may beassociated with a first smart contract address 6807A that may beassociated with the blockchain 6803 for the underlying digital asset. Inembodiments, the first smart contract instructions 6807B are saved inthe blockchain 6803 for the underlying digital asset. In embodiments,the first smart contract instructions 6807B include: first authorizationinstructions regarding creating stable value tokens (which may beincluded in the create stable value token module 6934); secondauthorization instructions regarding transferring stable valuetokens(which may be included in the transfer stable value token module6936); third authorization instructions regarding destroying stablevalue tokens (which may be included in the destroy stable value tokenmodule 6938); and fourth authorization instructions regarding functionsassociated with the stable value token (which may be included in theauthorization instruction module 6940). In embodiments, the first smartcontract instructions of the first stable value smart contract areassociated with more than one smart contract address. For example, SmartContract Address 6807A may be associated with a plurality of smartcontract addresses associated with the blockchain 6803 for theunderlying digital asset.

In embodiments, the method continues with the administrator systemgenerating the security token smart contract, which may be associatedwith a security token 6805 and second smart contract instructions 6805Bwhich may be associated with a second smart contract address 6805A whichmay be associated with the blockchain for the underlying digital asset.In embodiments, the second smart contract instructions 6805B are savedin the blockchain 6803 for the underlying digital asset. In embodiments,the second smart contract instructions 6805B include: first tradeinstructions for the security token smart contract (which may be similarto step S7016 described above in reference to FIG. 26B), fifthauthorization instructions regarding transferring security tokens (whichmay be included in transfer security tokens module 6920); sixthauthorization instructions regarding destroying security tokens (whichmay be included in destroy security tokens module 6922); seventhauthorization instructions regarding transferring stable value tokens tothe second contract address (which may be included in authorizeinstructions module 6926); eighth authorization instructions regardingtransferring stable value tokens from the second contract address (whichmay be included in authorize instructions module 6926); and calculatinginstructions regarding calculating excess collateral (which may beincluded in calculate excess collateral module 6928). In embodiments,the first trade instructions include execution instructions to execute afirst trade between the first user and the second user (which may beincluded in authorize instructions module 6926). In embodiments, thefirst trade is based on at least: the contract proposal and the firstuser response.

In embodiments, the method continues with the administrator systemsending the security token smart contract and associated second smartcontract instructions. In embodiments, the security token smart contractand associated second smart contract instructions 6805B may be sent viathe blockchain 6803 for the underlying digital asset to the second smartcontract address 6805A.

In embodiments, the method may continue with the second smart contractaddress 6805A receiving a first amount of collateral. In embodiments,the first amount of collateral may be a first amount of stable valuetokens associated with the first user as collateral. In embodiments, thefirst amount of stable value tokens associated with the first user isbased on the at least one collateral requirement 6910. In embodiments,the first user device 105 a may send a first message. The first messagemay include a request to transfer the first amount of collateral fromthe first user public address to the second smart contract address. Inembodiments, the first message may be sent via the underlying blockchain6803 from the first user public address associated with the underlyingblockchain 6803 to the first smart contract address 6807A associatedwith the underlying blockchain 6803. In embodiments, the first userdevice 105 a may send a second message to the first smart contractaddress 6807A. The second message may include authorization for thesecurity token smart contract to request a transfer of the first amountof collateral. In embodiments, the administrator system may send a thirdmessage including instructions to send a request from the second smartcontract address 6805A to the first smart contract address 6807A. Therequest, in embodiments, may be for the first amount of collateral to betransferred from the first user public address to the second smartcontract address 6805A. In embodiments, the third message is sent by theadministrator system via the underlying blockchain 6803 to the secondsmart contract address 6805A.

In embodiments, the method may continue with the second smart contractaddress 6805A receiving a second amount of collateral. In embodiments,the second amount of collateral may be a second amount stable valuetokens associated with the second user as collateral. In embodiments,the second amount of stable value tokens associated with the second useris based on the at least one collateral requirement 6910. Inembodiments, the second user device 105 b may send a fourth messageincluding a request. In embodiments, the request may be to transfer thesecond amount of collateral from the second user public address to thesecond smart contract address 6805A. In embodiments, the fourth messagemay be sent via the underlying blockchain 6803 from the second userpublic address associated with the underlying blockchain 6803 to thefirst smart contract address 6807A associated with the underlyingblockchain 6803. In embodiments, the second user device 105 b may send afifth message to the first smart contract address 6807A. The fifthmessage, in embodiments, may include authorization for the securitytoken smart contract to request a transfer of the second amount ofcollateral via the blockchain 6803. In embodiments, the administratorsystem may send a sixth message. The sixth message, in embodiments, mayinclude instructions to send a request. The request, in embodiments, maybe for the second amount of collateral to be transferred from the seconduser public address to the second smart contract address 6805A. Inembodiments, the sixth message is sent via the underlying blockchain6803 to the second smart contract address 6805A.

In embodiments, the first trade instructions are implemented via theblockchain for the underlying digital asset by computer systems amongthe plurality of geographically distributed computer systems in thepeer-to-peer network. In embodiments, the first trade instructions areimplemented as a result of a message sent from the administrator systemvia the blockchain 6803 to the second smart contract address 6805A.

In embodiments, the method may continue with the first collateral amountbeing recalculated based on the at least one collateral requirement 6910and current benchmark information (this may be similar to steps S6310and S6311, both described above in reference to FIG. 63C). Inembodiments, the recalculation may be performed by the first user device105 a. In embodiments, the recalculation is performed by theadministrator system. In embodiments, a first additional collateralamount may be determined based on a difference between the recalculatedfirst collateral amount and the first collateral amount. The firstadditional collateral amount may then be received at the second smartcontract address 6805A. In embodiments, the first additional collateralmay not be received. In embodiments, the administrator system maygenerate an alert. The alert, in embodiments, may include the firstadditional collateral amount. Once generated, the administrator systemmay send the alert to the first user device 105 a. In embodiments, thealert may be generated and sent by security token smart contract to thefirst user device 105 a (e.g., using the generate collateral informationmessage module 6930 and the send collateral information message module6932). Once the alert regarding the first additional collateral amountis received by the first user device 105 a, the method may continue withthe administrator system monitoring the second contract address 6805A onthe blockchain 6803 associated with the underlying digital asset (thismay be similar to step S7034 described above in reference to FIG. 26C).The administrator system may then, in embodiments, determine whether thefirst additional collateral amount is received by the second contractaddress 6805A (this may be similar to step S7034 described above inreference to FIG. 26C). If the first additional collateral is notreceived by the second contract address 6805A, the administrator systemmay generate a default notification. The default notification may besent by the administrator system to at least one of the first userdevice 105 a, the second user device 105 b, and the second smartcontract address 6805A. In embodiments, the default notification may begenerated and sent by security token smart contract to at least one ofthe first user device 105 a and the second user device 105 b (e.g.,using the generate collateral information message module 6930 and thesend collateral information message module 6932). After the defaultnotification is sent, the administrator system, in embodiments, maygenerate a seventh message. The seventh message, in embodiments, mayinclude a request to transfer the first collateral amount and the secondcollateral amount in accordance with the first trade instructions. Theseventh message may be sent by the administrator system to the secondsmart contract address 6805A. In embodiments, the transfers of the firstcollateral amount and the second collateral amount are implemented bythe plurality of geographically distributed computer systems in thepeer-to-peer network.

In embodiments, the method may continue with the second collateralamount being recalculated based on the at least one collateralrequirement 6910 and current benchmark information (this may be similarto steps 56310 and 56311, both described above in reference to FIG.63C). In embodiments, the recalculating step is performed by the seconduser device 105 b. In embodiments, the recalculating step is performedby the administrator system. In embodiments, a second additionalcollateral amount may be determined based on a difference between therecalculated second collateral amount and the second collateral amount.In embodiments, the second additional collateral amount is received atthe second smart contract address 6805A. In embodiments, the secondadditional collateral may not be received and the administrator systemmay generate an alert. The alert, in embodiments, may include the secondadditional collateral amount. Once generated, the administrator systemmay send the alert to the second user device 105 b. In embodiments, thealert may be generated and sent by security token smart contract to thesecond user device 105 b (e.g., using the generate collateralinformation message module 6930 and the send collateral informationmessage module 6932). Once the alert regarding the second additionalcollateral amount is received by the second user device 105 b, themethod may continue with the administrator system monitoring the secondsmart contract address 6805A on the blockchain 6803 associated with theunderlying digital asset (this may be similar to step S7034 describedabove in reference to FIG. 26C). The administrator system may monitorthe second smart contract address 6805A to determine whether the secondadditional collateral amount is received by the second contract address(this may be similar to step S7034 described above in reference to FIG.26C). If the administrator system determines that the second additionalcollateral amount is not received by the second smart contract address6805A, the administrator system may generate a default notification. Thedefault notification may be sent by the administrator system to at leastone of: the first user device 105 a, the second user device 105 b, andthe second smart contract address 6805A. In embodiments, the defaultnotification may be generated and sent by security token smart contractto at least one of the first user device 105 a and the second userdevice 105 b (e.g., using the generate collateral information messagemodule 6930 and the send collateral information message module 6932).After sending the default notification, the administrator system maygenerate an eighth message. The eighth message, in embodiments, mayinclude a request to transfer the first collateral amount and the secondcollateral amount in accordance with the first trade instructions. Theeighth message, In embodiments, may be sent by the administrator systemto the second smart contract address 6805A, where transfers of the firstcollateral amount and the second collateral amount are implemented bythe plurality of geographically distributed computer systems in thepeer-to-peer network.

In embodiments, the method may include the administrator systemdetermining, at the end of the contract duration, a payout amount basedon at least the first trade instructions. The payout instructions may begenerated by the administrator system. In embodiments, the payoutinstructions may be based at least on the first side information and thesecond side information (e.g. the first and/or second side informationincluding a leg of a contract described in FIGS. 27C-27F—ref nos. 7138,7144, 7154, 7160 respectively). The administrator system may, inembodiments, send the payout instructions to the second contract address6805A via the blockchain 6803 for the underlying digital asset. Thepayout instructions may provide the payout amount to one of the firstuser public address and the second user public address. The payoutamount, in embodiments, being based on at least the first tradeinstructions. In embodiments, the payout instructions are implemented bythe plurality of geographically distributed computer systems in thepeer-to-peer network.

In embodiments, the method may include the administrator systemcollecting excess collateral from the first trade (this may be similarto S7014 described above in reference to FIGS. 26A, 26E, and 26F). Theadministrator system may collect excess collateral by first sending aninth message to the second smart contract address 6805A via theunderlying blockchain 6803 for the underlying digital asset. The ninthmessage may include, in embodiments, requests for the security token to:determine first excess collateral for the first trade in accordance withthe security token smart contract (this may be similar to S7014described above in reference to FIGS. 26A, 26E, and 26F) and the firsttrade instructions; determine second excess collateral for the firsttrade in accordance with the security token smart contract and the firsttrade instructions (this may be similar to S7014 described above inreference to FIGS. 26A, 26E, and 26F); distribute the first excesscollateral for the first trade in accordance with the security tokensmart contract and the first trade instructions to the first useraddress (this may be similar to S7014 described above in reference toFIGS. 26A, 26E, and 26F); and distribute the second excess collateralfor the first trade in accordance with the security token smart contractand the first trade instructions to the second user address (this may besimilar to S7014 described above in reference to FIGS. 26A, 26E, and26F).

In embodiments, the administrator system may return the remainingcollateral from the first trade (this may be similar to S7014 describedabove in reference to FIGS. 26A, 26E, and 26F). The remainingcollateral, in embodiments, may be from the security token smartcontract. In embodiments, returning the remaining collateral may beginby the administrator system sending a tenth message to the second smartcontract address 6805. The tenth message, in embodiments, may includerequests for the security token smart contract to: determine firstremaining collateral for the first trade in accordance with the securitytoken smart contract and the first trade instructions (e.g. usingcalculate excess collateral module 6928); determine second remainingcollateral for the first trade in accordance with the security tokensmart contract and the first trade instructions (e.g. using calculateexcess collateral module 6928); distribute the first remainingcollateral for the first trade in accordance with the security tokensmart contract and the first trade instructions; and distribute thesecond remaining collateral for the first trade in accordance with thesecurity token smart contract and the first trade instructions (this maybe similar to S7014 described above in reference to FIGS. 26A, 26E, and26F).

In embodiments, a first benchmark value 6906 may be determined. Thefirst benchmark value 6906 may be determined by the security token smartcontract sending, via the blockchain 6803 for the underlying digitalasset, a request. The request may be sent from the second smart contractaddress 6805A to an oracle smart contract at a third contract addressassociated with the blockchain 6803 for the underlying digital asset(this may be similar to S7014 described above in reference to FIGS. 26A,26E, and 26F). The oracle smart contract may be associated with anoracle interface in contact with an authorized third party database. Therequest may include an eleventh message (this may be similar to S7014described above in reference to FIGS. 26A, 26E, and 26F). The eleventhmessage may include a request to obtain first benchmark value 6906 (thismay be similar to S7014 described above in reference to FIGS. 26A, 26E,and 26F). In response to the eleventh message, the oracle smart contractmay send the first benchmark value 6906 to the security token smartcontract (this may be similar to S7014 described above in reference toFIGS. 26A, 26E, and 26F). In response to receiving the first benchmarkvalue, the security token smart contract may execute instructions tostore the first benchmark value 6906.

In the case where the first excess collateral is greater than zero thefirst excess collateral may be calculated for the first user (this maybe similar to S7014 described above in reference to FIGS. 26A, 26E, and26F). In the case where the second excess collateral is greater thanzero, the second excess collateral may be calculated for the second user(this may be similar to S7014 described above in reference to FIGS. 26A,26E, and 26F). The first and second excess collateral, in embodiments,may be calculated using the first trade instructions and the firstbenchmark information 6906 (this may be similar to S7014 described abovein reference to FIGS. 26A, 26E, and 26F). Once the excess collateral iscalculated, the second smart contract address may send a twelfth messageto the first smart contract address. The twelfth message may include arequest for the stable value token smart contract to transfer the excesscollateral—the first excess collateral being requested to transfer ifgreater than zero and the second excess collateral being requested totransfer if greater than zero (this may be similar to S7014 describedabove in reference to FIGS. 26A, 26E, and 26F).

Now that embodiments of the present invention have been shown anddescribed in detail, various modifications and improvements thereon canbecome readily apparent to those skilled in the art. Accordingly, theexemplary embodiments of the present invention, as set forth above, areintended to be illustrative, not limiting. The spirit and scope of thepresent invention is to be construed broadly.

1. A method comprising: receiving, from a token issuer system andutilizing a blockchain, a first transaction request to remove a firstamount of digital asset tokens from a balance account, wherein the firsttransaction request is digitally signed by an authorized private keyassociated with a first smart contract used to determine the firsttransaction request is authorized; causing execution, via geographicallydistributed computer systems associated with the blockchain, of a firstcall request to obtain a second amount of digital asset tokens thatreflect a current balance of digital asset tokens in the balanceaccount; determining that the first amount of digital asset tokens isless than or equal to the second amount of digital asset tokens; basedat least in part on the first amount of digital asset tokens being lessthan or equal to the second amount of digital asset tokens, causingexecution, via the geographically distributed computer systems, of asecond call request to set a new balance for the digital asset tokens toa third amount that equals the second amount less the first amount;causing execution, via the geographically distributed computer systems,of a third call request to obtain a total supply of digital asset tokensin circulation; and sending instructions to cause the blockchain to setthe total supply of digital asset tokens in circulation to a fourthamount that is the third amount less the first amount.
 2. The method ofclaim 1, further comprising: providing a first designated key pair,including a first designated public key and a corresponding firstdesignated private key, wherein the first designated public key alsocorresponds to a first designated public address associated with anunderlying digital asset, wherein the underlying digital asset ismaintained on a distributed public transaction ledger maintained by thegeographically distributed computer systems, and wherein the firstdesignated private key is stored on a first computer system which isconnected to the distributed public transaction ledger; providing asecond designated key pair, including a second designated public key anda corresponding second designated private key, wherein the seconddesignated public key also corresponds to a second designated publicaddress associated with the underlying digital asset, and wherein thesecond designated private key is stored on a second computer systemwhich is physically separated from the first computer system and is notoperatively or physically connected to the distributed publictransaction ledger; and wherein the authorized private key correspondsto at least one of the first designated private key or the seconddesignated private key.
 3. The method of claim 2, further comprising:providing first smart contract instructions for the first smartcontract, the first smart contract associated with a first contractaddress, wherein the first smart contract instructions are saved as partof the blockchain for the underlying digital asset and include: firstdelegation instructions to delegate one or more first functionsassociated with the digital asset tokens to one or more delegatedcontract addresses associated with the blockchain, wherein the one ormore delegated contract addresses differ from the first contractaddress, and wherein a second contract address is designated as one ofthe one or more delegated contract addresses; and first authorizationinstructions for the second designated key pair.
 4. The method of claim2, further comprising: providing second smart contract instructions fora second smart contract, the second smart contract associated with asecond contract address, wherein the second smart contract instructionsare saved as part of the blockchain for the underlying digital asset andinclude: print limiter token creation instructions indicating conditionsunder which tokens of the digital asset tokens are created; secondauthorization instructions to create tokens of the digital asset tokens,wherein the first designated key pair is designated to authorize thesecond authorization instructions to create tokens of the digital assettokens; and third authorization instructions with respect to tokencreation of the digital asset tokens, wherein the third authorizationinstructions designate a first designated custodian address with respectto token creation of the digital asset tokens.
 5. The method of claim 4,further comprising: providing third smart contract instructions for afirst designated custodian smart contract associated with a thirdcontract address, wherein the third contract address is the firstdesignated custodian address, and wherein the third smart contractinstructions are saved as part of the blockchain associated with theunderlying digital asset and include fourth authorization instructionsto authorize issuance of instructions to the second smart contractregarding token creation, wherein the fourth authorization instructionsdesignate the second designated key pair to authorize the fourthauthorization instructions.
 6. The method of claim 2, furthercomprising: providing fourth smart contract instructions for a fourthsmart contract associated with a fourth contract address, wherein thefourth smart contract instructions are saved as part of the blockchainassociated with the underlying digital asset and include: token creationinstructions to create tokens of the digital asset tokens in accordancewith conditions set forth by print limiter token creation instructions;and second delegation instructions delegating data storage operations toat least another contract address.
 7. The method of claim 6, furthercomprising: providing fifth smart contract instructions for a fifthsmart contract associated with a fifth contract address, wherein thefifth contract instructions are saved as part of the blockchain for theunderlying digital asset and include: data storage instructions fortransaction data related to the digital asset tokens, wherein thetransaction data includes for issued tokens of the digital asset tokens:respective public address information associated with the blockchainassociated with the underlying digital asset; and correspondingrespective token balance information associated with the respectivepublic address information; and fifth authorization instructions tomodify the transaction data in response to requests from the fourthcontract address.
 8. A system comprising: one or more processors; andnon-transitory computer-readable media storing instructions that, whenexecuted by the one or more processors, cause the one or more processorsto perform operations comprising: receiving, from a token issuer systemand utilizing a blockchain, a first transaction request to remove afirst amount of digital asset tokens from a balance account, wherein thefirst transaction request is digitally signed by an authorized privatekey associated with a first smart contract used to determine the firsttransaction request is authorized; causing execution, via geographicallydistributed computer systems associated with the blockchain, of a firstcall request to obtain a second amount of digital asset tokens thatreflect a current balance of digital asset tokens in the balanceaccount; determining that the first amount of digital asset tokens isless than or equal to the second amount of digital asset tokens; basedat least in part on the first amount of digital asset tokens being lessthan or equal to the second amount of digital asset tokens, causingexecution, via the geographically distributed computer systems, of asecond call request to set a new balance for the digital asset tokens toa third amount that equals the second amount less the first amount;causing execution, via the geographically distributed computer systems,of a third call request to obtain a total supply of digital asset tokensin circulation; and sending instructions to cause the blockchain to setthe total supply of digital asset tokens in circulation to a fourthamount that is the third amount less the first amount.
 9. The system ofclaim 8, the operations further comprising causing the first smartcontract to execute, via the geographically distributed computersystems, based at least in part on receiving the first transactionrequest.
 10. The system of claim 8, the operations further comprising:providing a first designated key pair, including a first designatedpublic key and a corresponding first designated private key, wherein thefirst designated public key also corresponds to a first designatedpublic address associated with an underlying digital asset, wherein theunderlying digital asset is maintained on a distributed publictransaction ledger maintained by the geographically distributed computersystems, and wherein the first designated private key is stored on afirst computer system which is connected to the distributed publictransaction ledger; providing a second designated key pair, including asecond designated public key and a corresponding second designatedprivate key, wherein the second designated public key also correspondsto a second designated public address associated with the underlyingdigital asset, and wherein the second designated private key is storedon a second computer system which is physically separated from the firstcomputer system and is not operatively or physically connected to thedistributed public transaction ledger; and wherein the authorizedprivate key corresponds to at least one of the first designated privatekey or the second designated private key.
 11. The system of claim 10,the operations further comprising: providing first smart contractinstructions for the first smart contract, the first smart contractassociated with a first contract address, wherein the first smartcontract instructions are saved as part of the blockchain for theunderlying digital asset and include: first delegation instructions todelegate one or more first functions associated with the digital assettokens to one or more delegated contract addresses associated with theblockchain, wherein the one or more delegated contract addresses differfrom the first contract address, and wherein a second contract addressis designated as one of the one or more delegated contract addresses;and first authorization instructions for the second designated key pair.12. The system of claim 10, further comprising: providing second smartcontract instructions for a second smart contract, the second smartcontract associated with a second contract address, wherein the secondsmart contract instructions are saved as part of the blockchain for theunderlying digital asset and include: print limiter token creationinstructions indicating conditions under which tokens of the digitalasset tokens are created; second authorization instructions to createtokens of the digital asset tokens, wherein the first designated keypair is designated to authorize the second authorization instructions tocreate tokens of the digital asset tokens; and third authorizationinstructions with respect to token creation of the digital asset tokens,wherein the third authorization instructions designate a firstdesignated custodian address with respect to token creation of thedigital asset tokens.
 13. The system of claim 12, the operations furthercomprising: providing third smart contract instructions for a firstdesignated custodian smart contract associated with a third contractaddress, wherein the third contract address is the first designatedcustodian address, and wherein the third smart contract instructions aresaved as part of the blockchain associated with the underlying digitalasset and include fourth authorization instructions to authorizeissuance of instructions to the second smart contract regarding tokencreation, wherein the fourth authorization instructions designate thesecond designated key pair to authorize the fourth authorizationinstructions.
 14. The system of claim 10, the operations furthercomprising: providing fourth smart contract instructions for a fourthsmart contract associated with a fourth contract address, wherein thefourth smart contract instructions are saved as part of the blockchainassociated with the underlying digital asset and include: token creationinstructions to create tokens of the digital asset tokens in accordancewith conditions set forth by print limiter token creation instructions;and second delegation instructions delegating data storage operations toat least another contract address.
 15. The system of claim 14, theoperations further comprising: providing fifth smart contractinstructions for a fifth smart contract associated with a fifth contractaddress, wherein the fifth contract instructions are saved as part ofthe blockchain for the underlying digital asset and include: datastorage instructions for transaction data related to the digital assettokens, wherein the transaction data includes for issued tokens of thedigital asset tokens: respective public address information associatedwith the blockchain associated with the underlying digital asset; andcorresponding respective token balance information associated with therespective public address information; and fifth authorizationinstructions to modify the transaction data in response to requests fromthe fourth contract address.
 16. A method comprising: providing a firstdesignated key pair, including a first designated public key and acorresponding first designated private key, wherein the first designatedpublic key also corresponds to a first designated public addressassociated with an underlying digital asset, wherein the underlyingdigital asset is maintained on a distributed public transaction ledgermaintained by geographically distributed computer systems; receiving,from a token issuer system and utilizing a blockchain, a firsttransaction request to remove a first amount of digital asset tokensfrom a balance account, wherein the first transaction request isdigitally signed by the first designated private key associated with afirst smart contract used to determine the first transaction request isauthorized; causing execution, via geographically distributed computersystems associated with the blockchain, of a first call request toobtain a second amount of digital asset tokens that reflect a currentbalance of digital asset tokens in the balance account; determining thatthe first amount of digital asset tokens is less than or equal to thesecond amount of digital asset tokens; based at least in part on thefirst amount of digital asset tokens being less than or equal to thesecond amount of digital asset tokens, causing execution, via thegeographically distributed computer systems, of a second call request toset a new balance for the digital asset tokens to a third amount thatequals the second amount less the first amount; causing execution, viathe geographically distributed computer systems, of a third call requestto obtain a total supply of digital asset tokens in circulation; andsending instructions to cause the blockchain to set the total supply ofdigital asset tokens in circulation to a fourth amount that is the thirdamount less the first amount.
 17. The method of claim 16, furthercomprising providing smart contract instructions for a second smartcontract, the second smart contract associated with a second contractaddress, wherein the smart contract instructions are saved as part ofthe blockchain for the underlying digital asset and include instructionsfor modifying the total supply of the digital asset tokens.
 18. Themethod of claim 16, wherein: causing execution of the first callcomprises causing execution of the first call based at least in part onfirst smart contract instructions; causing execution of the second callcomprises causing execution of the second call based at least in part onsecond smart contract instructions that differ from the first smartcontract instructions; and causing execution of the third call comprisescausing execution of the third call based at least in part on thirdsmart contract instructions that differ from both the first smartcontract instructions and the second smart contract instructions. 19.The method of claim 16, further comprising authorizing the firsttransaction request based at least in part on designated publicaddresses associated with public keys for the first transaction request,designated private addresses associated with private keys for the firsttransaction request, and smart contract instructions indicatingauthorized designated public addresses and authorized designated privateaddresses.
 20. The method of claim 16, further comprising sending aresponse to the first transaction request, the response indicating thatthe first transaction request has been accepted and indicating the totalsupply of the digital asset tokens has been set to the fourth amount.